Get started

Search in scripts for "THE SCRIPT"

Delta Volume Candles [LucF]█  OVERVIEW This indicator plots on-chart volume delta information using candles that can replace your normal candles, tops and bottoms appended to normal candles, optional MAs of those tops and bottoms levels, a divergence channel and a chart background. The indicator calculates volume delta using intrabar analysis, meaning that it uses the lower timeframe bars constituting each chart bar. █  CONCEPTS Volume Delta ​The ​volume delta concept divides a bar's ​volume in "up" and "down" ​volumes. The delta is calculated by subtracting down ​volume from up ​volume. Many calculation techniques exist to isolate up and down ​volume within a bar. The simplest use the polarity of interbar price changes to assign their ​volume to up or down slots, e.g., On Balance Volume or the Klinger Oscillator . Others such as Chaikin Money Flow use assumptions based on a bar's OHLC values. The most precise calculation method uses tick data and assigns the ​volume of each tick to the up or down slot depending on whether the transaction occurs at the bid or ask price. While this technique is ideal, it requires huge amounts of data on historical bars, which considerably limits the historical depth of charts and the number of symbols for which tick data is available. Furthermore, historical tick data is not yet available on TradingView. This indicator uses intrabar analysis to achieve a compromise between the simplest and most precise methods of calculating ​volume delta. It is currently the most precise method usable on TradingView charts. TradingView's Volume Profile built-in indicators use it, as do the CVD - Cumulative ​Volume Delta Candles and CVD - Cumulative Volume Delta (Chart) indicators published from the TradingView account . My Delta Volume Channels and Volume Delta Columns Pro indicators also use intrabar analysis. Other ​volume delta indicators such as my Realtime 5D Profile use realtime chart updates to calculate volume delta without intrabar analysis, but that type of indicator only works in real time; they cannot calculate on historical bars. This is the logic I use to determine the polarity of intrabars, which determines the up or down slot where its ​volume is added:  • If the intrabar's open and close values are different, their relative position is used.  • If the intrabar's open and close values are the same, the difference between the intrabar's close and the previous intrabar's close is used.  • As a last resort, when there is no movement during an intrabar, and it closes at the same price as the previous intrabar, the last known polarity is used. Once all intrabars making up a chart bar have been analyzed and the up or down property of each intrabar's ​volume determined, the up volumes are added, and the down volumes subtracted. The resulting value is ​volume delta for that chart bar, which can be used as an estimate of the buying/selling pressure on an instrument. Not all markets have volume information. Without it, this indicator is useless. Intrabar analysis Intrabars are chart bars at a lower timeframe than the chart's. The timeframe used to access intrabars determines the number of intrabars accessible for each chart bar. On a 1H chart, each chart bar of an active market will, for example, usually contain 60 bars at the lower timeframe of 1min, provided there was market activity during each minute of the hour. This indicator automatically calculates an appropriate lower timeframe using the chart's timeframe and the settings you use in the script's "Intrabars" section of the inputs. As it can access lower timeframes as small as seconds when available, the indicator can be used on charts at relatively small timeframes such as 1min, provided the market is active enough to produce bars at second timeframes. The quantity of intrabars analyzed in each chart bar determines:  • The precision of calculations (more intrabars yield more precise results).  • The chart coverage of calculations (there is a 100K limit to the quantity of intrabars that can be analyzed on any chart,   so the more intrabars you analyze per chart bar, the less chart bars can be calculated by the indicator). The information box displayed at the bottom right of the chart shows the lower timeframe used for intrabars, as well as the average number of intrabars detected for chart bars and statistics on chart coverage. Balances This indicator calculates five balances from volume delta values. The balances are oscillators with a zero centerline; positive values are bullish, and negative values are bearish. It is important to understand the balances as they can be used to:  • Color candle bodies.  • Calculate body and top and bottom divergences.  • Color an EMA channel.  • Color the chart's background.  • Configure markers and alerts. The five balances are: 1 — Bar Balance : This is the only balance using instant values; it is simply the subtraction of the down volume​ from the up volume​ on the bar, so the instant volume delta for that bar. 2 — Average Balance : Calculates a distinct EMA for both the up and down volumes, and subtracts the down EMA from the up EMA.   The result is akin to MACD's histogram because it is the subtraction of two moving averages. 3 — Momentum Balance : Starts by calculating, separately for both up and down volumes, the difference between the same EMAs used in "Average Balance" and   an SMA of twice the period used for the "Average Balance" EMAs. The difference for the up side is subtracted from the difference for the down side,   and an RSI of that value is calculated and brought over the −50/+50 scale. 4 — Relative Balance : The reference values used in the calculation are the up and down EMAs used in the "Average Balance".   From those, we calculate two intermediate values using how much the instant up and down volumes on the bar exceed their respective EMA — but with a twist.   If the bar's up volume​ does not exceed the EMA of up volume​, a zero value is used. The same goes for the down volume​ with the EMA of down volume​.   Once we have our two intermediate values for the up and down volumes exceeding their respective MA, we subtract them. The final value is an ALMA of that subtraction.   The rationale behind using zero values when the bar's up/down volume​ does not exceed its EMA is to only take into account the more significant volume​.   If both instant volume​ values exceed their MA, then the difference between the two is the signal's value.   The signal is called "relative" because the intermediate values are the difference between the instant up/down volumes and their respective MA.   This balance flatlines when the bar's up/down volumes do not exceed their EMAs, which makes it useful to spot areas where trader interest dwindles, such as consolidations.   The smaller the period of the final value's ALMA, the more easily it will flatline. These flat zones should be considered no-trade zones. 5 — Percent Balance : This balance is the ALMA of the ratio of the "Bar Balance" over the total volume for that bar. From the balances and marker conditions, two more values are calculated: 1 — Marker Bias : This sums the up/down (+1/‒1) occurrences of the markers 1 to 4 over a period you define, so it ranges from −4 to +4, times the period.   Its calculation will depend on the modes used to calculate markers 3 and 4. 2 — Combined Balances : This is the sum of the bull/bear (+1/−1) states of each of the five balances, so it ranges from −5 to +5. The periods for all of these balances can be configured in the "Periods" section at the bottom of the script's inputs. As you cannot see the balances on the chart, you can use my Volume Delta Columns Pro indicator in a pane; it can plot the same balances, so you will be able to analyze them. Divergences In the context of this indicator, a divergence is any bar where the bear/bull state of a balance (above/below its zero centerline) diverges from the polarity of a chart bar. No directional bias is assigned to divergences when they occur. Candle bodies and tops/bottoms can each be colored differently on divergences detected from distinct balances. Divergence Channel The divergence channel is the space between two levels (by default, the bar's open and close ) saved when divergences occur. When price (by default the close ) has breached a channel and a new divergence occurs, a new channel is created. Until that new channel is breached, bars where additional divergences occur will expand the channel's levels if the bar's price points are outside the channel. Prices breaches of the divergence channel will change its state. Divergence channels can be in one of three different states:  • Bull (green): Price has breached the channel to the upside.  • Bear (red): Price has breached the channel to the downside.  • Neutral (gray): The channel has not yet been breached. █  HOW TO USE THE INDICATOR I do not make videos to explain how to use my indicators. I do, however, try hard to include in their description everything one needs to understand what they do. From there, it's up to you to explore and figure out if they can be useful in your trading practice. Communicating in videos what this description and the script's tooltips contain would make for very long videos that would likely exceed the attention span of most people who find this description too long. There is no quick way to understand an indicator such as this one because it uses many different concepts and has quite a bit of settings one can use to modify its visuals and behavior — thus how one uses it. I will happily answer questions on the inner workings of the indicator, but I do not answer questions like "How do I trade using this indicator?" A useful answer to that question would require an in-depth analysis of who you are, your trading methodology and objectives, which I do not have time for. I do not teach trading. Start by loading the indicator on an active chart containing volume information. See here if you need help. The default configuration displays:  • Normal candles where the bodies are only colored if the bar's volume has increased since the last bar.   If you want to use this indicator's candles, you may want to disable your chart's candles by clicking the eye icon to the right of the symbol's name in the top left of the chart.  • A top or bottom appended to the normal candles. It represents the difference between up and down volume for that bar   and is positioned at the top or bottom, depending on its polarity. If up volume is greater than down volume, a top is displayed. If down volume is greater, a bottom is plotted.   The size of tops and bottoms is determined by calculating a factor which is the proportion of volume delta over the bar's total volume.   That factor is then used to calculate the top or bottom size relative to a baseline of the average candle body size of the last 100 bars.  • An information box in the bottom right displaying intrabar and chart coverage information.  • A light red background when the intrabar volume differs from the chart's volume by more than 1%. The script's inputs contain tooltips explaining most of the fields. I will not repeat them here. Following is a brief description of each section of the indicator's inputs which will give you an idea of what the indicator can do: Normal Candles is where you configure the replacement candles plotted by the script. You can choose from different coloring schemes for their bodies and specify a unique color for bodies where a divergence calculated using the method you choose occurs. Volume Tops & Botttoms is where you configure the display of tops and bottoms, and their EMAs. The EMAs are calculated from the high point of tops and the low point of bottoms. They can act as a channel to evaluate price, and you can choose to color the channel using a gradient reflecting the advances/declines in the balance of your choice. Divergence Channel is where you set up the appearance and behavior of the divergence channel. These areas represent levels where price and volume delta information do not converge. They can be interpreted as regions with no clear direction from where one will look for breaches. You can configure the channel to take into account one or both types of divergences you have configured for candle bodies and tops/bottoms. Background allows you to configure a gradient background color that reflects the advances/declines in the balance of your choice. You can use this to provide context to the volume delta values from bars. You can also control the background color displayed on volume discrepancies between the intrabar and the chart's timeframe. Intrabars is where you choose the calculation mode determining the lower timeframe used to access intrabars. The indicator uses the chart's timeframe and the type of market you are on to calculate the lower timeframe. Your setting there should reflect which compromise you prefer between the precision of calculations and chart coverage. This is also where you control the display of the information box in the lower right corner of the chart. Markers allows you to control the plotting of chart markers on different conditions. Their configuration determines when alerts generated from the indicator will fire. Note that in order to generate alerts from this script, they must be created from your chart. See this Help Center page to learn how. Only the last 500 markers will be visible on the chart, but this will not affect the generation of alerts. Periods is where you configure the periods for the balances and the EMAs used in the indicator. The raw values calculated by this script can be inspected using the Data Window. █  INTERPRETATION Rightly or wrongly, volume delta is considered by many a useful complement to the interpretation of price action. I use it extensively in an attempt to find convergence between my read of volume delta and price movement — not so much as a predictor of future price movement. No system or person can predict the future. Accordingly, I consider people who speak or act as if they know the future with certainty to be dangerous to themselves and others; they are charlatans, imprudent or blissfully ignorant. I try to avoid elaborate volume delta interpretation schemes involving too many variables and prefer to keep things simple:  • Trends that have more chances of continuing should be accompanied by VD of the same polarity.   In trends, I am looking for "slow and steady". I work from the assumption that traders and systems often overreact, which translates into unproductive volatility.   Wild trends are more susceptible to overreactions.  • I prefer steady VD values over wildly increasing ones, as large VD increases often come with increased price volatility, which can backfire.   Large VD values caused by stopping volume will also often occur on trend reversals with abnormally high candles.  • Prices escaping divergence channels may be leading a trend in that direction, although there is no telling how long that trend will last; could be just a few bars or hundreds.   When price is in a channel, shifts in VD balances can sometimes give us an idea of the direction where price has the most chance of breaking.  • Dwindling VD will often indicate trend exhaustion and predate reversals by many bars, but the problem is that mere pauses in a trend will often produce the same behavior in VD.   I think it is too perilous to infer rigidly from VD decreases. Divergence Channel Here I have configured the divergence channels to be visible. First, I set the bodies to display divergences on the default Bar Balance. They are indicated by yellow bodies. Then I activated the divergence channels by choosing to draw levels on body divergences and checked the "Fill" checkbox to fill the channel with the same color as the levels. The divergence channel is best understood as a direction-less area from where a breach can be acted on if other variables converge with the breach's direction: Tops and Bottoms EMAs I find these EMAs rather interesting. They have no equivalent elsewhere, as they are calculated from the top and bottom values this indicator plots. The only similarity they have with volume-weighted MAs, including VWAP, is that they use price and volume. This indicator's Tops and Bottoms EMAs, however, use the price and volume delta. While the channel differs from other channels in how it is calculated, it can be used like others, as a baseline from which to evaluate price movement or, alternatively, as stop levels. Remember that you can change the period used for the EMAs in the "Periods" section of the inputs. This chart shows the EMAs in action, filled with a gradient representing the advances/decline from the Momentum balance. Notice the anomaly in the chart's latest bars where the Momentum balance gradient has been indicating a bullish bias for some time, during which price was mostly below the EMAs. Price has just broken above the channel on positive VD. My interpretation of this situation would be that it is a risky opportunity for a long trade in the larger context where the market has been in a downtrend since the 5th. Intrepid traders choosing to enter here could do so with a "make or break" tight stop that will minimize their losses should the market continue its downtrend while hopefully preserving the potential upside of price continuing on the longer-term uptrend prevalent since the 28th: █  NOTES Volume If you use indicators such as this one which depends on volume information, it is important to realize that the volume data they consume comes from data feeds, and that all data feeds are NOT created equally. Those who create the data feeds we use must make decisions concerning the nature of the transactions they tally and the way they are tallied in each feed, and these decisions affect the nature of our volume data. My Volume X-ray publication discusses some of the reasons why volume information from different timeframes, brokers/exchanges or sectors may vary considerably. I encourage you to read it. This indicator's display of a warning through a background color on volume discrepancies between the timeframe used to access intrabars and the chart's timeframe is an attempt to help you realize these variations in feeds. Don't take things for granted, and understand that the quality of a given feed's volume information affects the quality of the results this indicator calculates. Markets as ecosystems I believe it is perilous to think that behavioral patterns you discover in one market through the lens of this or any other indicator will necessarily port to other markets. While this may sometimes be the case, it will often not. Why is that? Because each market is its own ecosystem. As cities do, all markets share some common characteristics, but they also all have their idiosyncrasies. A proportion of a city's inhabitants is always composed of outsiders who come and go, but a core population of regulars and systems is usually the force that actually defines most of the city's observable characteristics. I believe markets work somewhat the same way; they may look the same, but if you live there for a while and pay attention, you will notice the idiosyncrasies. Some things that work in some markets will, accordingly, not work in others. Please keep that in mind when you draw conclusions. On Up/Down or Buy/Sell Volume Buying or selling volume are misnomers, as every unit of volume transacted is both bought and sold by two different traders. While this does not keep me from using the terms, there is no such thing as “buy only” or “sell only” volume. Trader lingo is riddled with peculiarities. Without access to order book information, traders work with the assumption that when price moves up during a bar, there was more buying pressure than selling pressure, just as when buy market orders take out limit ask orders in the order book at successively higher levels. The built-in volume indicator available on TradingView uses this logic to color the volume columns green or red. While this script’s calculations are more precise because it analyses intrabars to calculate its information, it uses pretty much the same imperfect logic. Until Pine scripts can have access to how much volume was transacted at the bid/ask prices, our volume delta calculations will remain a mere proxy. Repainting  • The values calculated on the realtime bar will update as new information comes from the feed.  • Historical values may recalculate if the historical feed is updated or when calculations start from a new point in history.  • Markers and alerts will not repaint as they only occur on a bar's close. Keep this in mind when viewing markers on historical bars,   where one could understandably and incorrectly assume they appear at the bar's open. To learn more about repainting, see the Pine Script™ User Manual's page on the subject . Superfluity In "The Bed of Procrustes", Nassim Nicholas Taleb writes: To bankrupt a fool, give him information . This indicator can display a lot of information. The inevitable adaptation period you will need to figure out how to use it should help you eliminate all the visuals you do not need. The more you eliminate, the easier it will be to focus on those that are the most useful to your trading practice. Don't be a fool. █  THANKS Thanks to alexgrover for his Dekidaka-Ashi indicator. His volume plots on candles were the inspiration for my top/bottom plots. Kudos to PineCoders for their libraries. I use two of them in this script: Time and lower_tf . The first versions of this script used functionality that I would not have known about were it not for these two guys: — A guy called Kuan who commented on a Backtest Rookies presentation of their Volume Profile indicator. — theheirophant , my partner in the exploration of the sometimes weird abysses of request.security() ’s behavior at lower timeframes.
Pine Script™ indicator
by LucF
113
PSESS1 - Learn PineScript InputsThis is a script written exclusively for people who are trying to learn Pine Script. PSESS stands for "Pine Script Educational Script Series" which is a series of scripts that helps Pine Script programmers in 2 ways: 1. Learn Pine Script at more depth by an interactive environment where they can immediately see the effects of any change in the pre-written code and also comparing different lines code having tiny differences so they can grasp the details. 2. Have this script open while coding in order to copy the line they find useful Pine Script Library couldn't be used for this purpose since this script has educational aspect and needs to be executable individually. This is Script 1 of PSESS and focuses on inputs in Pine Script. The script is densly commented in order to make it understandable. here is the outline of the script: 1. Inputs that can be received through the indicator() function 2. 12 possible types of input 3. Input() function arguments: defval - title - tooltip - inline - group - confirm 4. The different display of tooltip when inputs are inline 5. Multiple price and time inputs (on single request or multiple requests) 6. What happens when title argument is not specified 7. References and key points from them
Pine Script™ indicator
by Mahdi_Fatemi1998
`security()` revisited [PineCoders]NOTE The non-repainting technique in this publication that relies on bar states is now deprecated, as we have identified inconsistencies that undermine its credibility as a universal solution. The outputs that use the technique are still available for reference in this publication. However, we do not endorse its usage. See this publication for more information about the current best practices for requesting HTF data and why they work. █  OVERVIEW This script presents a new function to help coders use security() in both repainting and non-repainting modes. We revisit this often misunderstood and misused function, and explain its behavior in different contexts, in the hope of dispelling some of the coder lure surrounding it. The function is incredibly powerful, yet misused, it can become a dangerous WMD and an instrument of deception, for both coders and traders. We will discuss:  • How to use our new `f_security()` function.  • The behavior of Pine code and security() on the three very different types of bars that make up any chart.  • Why what you see on a chart is a simulation, and should be taken with a grain of salt.  • Why we are presenting a new version of a function handling security() calls.  • Other topics of interest to coders using higher timeframe (HTF) data. █  WARNING We have tried to deliver a function that is simple to use and will, in non-repainting mode, produce reliable results for both experienced and novice coders. If you are a novice coder, stick to our recommendations to avoid getting into trouble, and DO NOT change our `f_security()` function when using it. Use `false` as the function's last argument and refrain from using your script at smaller timeframes than the chart's. To call our function to fetch a non-repainting value of close from the 1D timeframe, use: f_security(_sym, _res, _src, _rep) => security(_sym, _res, _src ) previousDayClose = f_security(syminfo.tickerid, "D", close, false) If that's all you're interested in, you are done. If you choose to ignore our recommendation and use the function in repainting mode by changing the `false` in there for `true`, we sincerely hope you read the rest of our ramblings before you do so, to understand the consequences of your choice. Let's now have a look at what security() is showing you. There is a lot to cover, so buckle up! But before we dig in, one last thing. What is a chart? A chart is a graphic representation of events that occur in markets. As any representation, it is not reality, but rather a model of reality. As Scott Page eloquently states in The Model Thinker : "All models are wrong; many are useful". Having in mind that both chart bars and plots on our charts are imperfect and incomplete renderings of what actually occurred in realtime markets puts us coders in a place from where we can better understand the nature of, and the causes underlying the inevitable compromises necessary to build the data series our code uses, and print chart bars. Traders or coders complaining that charts do not reflect reality act like someone who would complain that the word "dog" is not a real dog. Let's recognize that we are dealing with models here, and try to understand them the best we can. Sure, models can be improved; TradingView is constantly improving the quality of the information displayed on charts, but charts nevertheless remain mere translations. Plots of data fetched through security() being modelized renderings of what occurs at higher timeframes, coders will build more useful and reliable tools for both themselves and traders if they endeavor to perfect their understanding of the abstractions they are working with. We hope this publication helps you in this pursuit. █  FEATURES This script's "Inputs" tab has four settings:  • Repaint : Determines whether the functions will use their repainting or non-repainting mode.   Note that the setting will not affect the behavior of the yellow plot, as it always repaints.  • Source : The source fetched by the security() calls.  • Timeframe : The timeframe used for the security() calls. If it is lower than the chart's timeframe, a warning appears.  • Show timeframe reminder : Displays a reminder of the timeframe after the last bar. █  THE CHART The chart shows two different pieces of information and we want to discuss other topics in this section, so we will be covering:  A — The type of chart bars we are looking at, indicated by the colored band at the top.  B — The plots resulting of calling security() with the close price in different ways.  C — Points of interest on the chart. A — Chart bars The colored band at the top shows the three types of bars that any chart on a live market will print. It is critical for coders to understand the important distinctions between each type of bar:  1 — Gray : Historical bars, which are bars that were already closed when the script was run on them.  2 — Red : Elapsed realtime bars, i.e., realtime bars that have run their course and closed.    The state of script calculations showing on those bars is that of the last time they were made, when the realtime bar closed.  3 — Green : The realtime bar. Only the rightmost bar on the chart can be the realtime bar at any given time, and only when the chart's market is active. Refer to the Pine User Manual's Execution model page for a more detailed explanation of these types of bars. B — Plots The chart shows the result of letting our 5sec chart run for a few minutes with the following settings: "Repaint" = "On" (the default is "Off"), "Source" = `close` and "Timeframe" = 1min. The five lines plotted are the following. They have progressively thinner widths:  1 — Yellow : A normal, repainting security() call.  2 — Silver : Our recommended security() function.  3 — Fuchsia : Our recommended way of achieving the same result as our security() function, for cases when the source used is a function returning a tuple.  4 — White : The method we previously recommended in our MTF Selection Framework , which uses two distinct security() calls.  5 — Black : A lame attempt at fooling traders that MUST be avoided. All lines except the first one in yellow will vary depending on the "Repaint" setting in the script's inputs. The first plot does not change because, contrary to all other plots, it contains no conditional code to adapt to repainting/no-repainting modes; it is a simple security() call showing its default behavior. C — Points of interest on the chart Historical bars do not show actual repainting behavior To appreciate what a repainting security()  call will plot in realtime, one must look at the realtime bar and at elapsed realtime bars, the bars where the top line is green or red on the chart at the top of this page. There you can see how the plots go up and down, following the close value of each successive chart bar making up a single bar of the higher timeframe. You would see the same behavior in "Replay" mode. In the realtime bar, the movement of repainting plots will vary with the source you are fetching: open will not move after a new timeframe opens, low and high will change when a new low or high are found, close will follow the last feed update. If you are fetching a value calculated by a function, it may also change on each update. Now notice how different the plots are on historical bars. There, the plot shows the close of the previously completed timeframe for the whole duration of the current timeframe, until on its last bar the price updates to the current timeframe's close when it is confirmed (if the timeframe's last bar is missing, the plot will only update on the next timeframe's first bar). That last bar is the only one showing where the plot would end if that timeframe's bars had elapsed in realtime. If one doesn't understand this, one cannot properly visualize how his script will calculate in realtime when using repainting. Additionally, as published scripts typically show charts where the script has only run on historical bars, they are, in fact, misleading traders who will naturally assume the script will behave the same way on realtime bars. Non-repainting plots are more accurate on historical bars Now consider this chart, where we are using the same settings as on the chart used to publish this script, except that we have turned "Repainting" off this time: The yellow line here is our reference, repainting line, so although repainting is turned off, it is still repainting, as expected. Because repainting is now off, however, plots on historical bars show the previous timeframe's close until the first bar of a new timeframe, at which point the plot updates. This correctly reflects the behavior of the script in the realtime bar, where because we are offsetting the series by one, we are always showing the previously calculated—and thus confirmed—higher timeframe value. This means that in realtime, we will only get the previous timeframe's values one bar after the timeframe's last bar has elapsed, at the open of the first bar of a new timeframe. Historical and elapsed realtime bars will not actually show this nuance because they reflect the state of calculations made on their close , but we can see the plot update on that bar nonetheless. ► This more accurate representation on historical bars of what will happen in the realtime bar is one of the two key reasons why using non-repainting data is preferable.    The other is that in realtime, your script will be using more reliable data and behave more consistently. Misleading plots Valiant attempts by coders to show non-repainting, higher timeframe data updating earlier than on our chart are futile. If updates occur one bar earlier because coders use the repainting version of the function, then so be it, but they must then also accept that their historical bars are not displaying information that is as accurate. Not informing script users of this is to mislead them. Coders should also be aware that if they choose to use repainting data in realtime, they are sacrificing reliability to speed and may be running a strategy that behaves very differently from the one they backtested, thus invalidating their tests. When, however, coders make what are supposed to be non-repainting plots plot artificially early on historical bars, as in examples "c4" and "c5" of our script, they would want us to believe they have achieved the miracle of time travel. Our understanding of the current state of science dictates that for now, this is impossible. Using such techniques in scripts is plainly misleading, and public scripts using them will be moderated. We are coding trading tools here—not video games. Elementary ethics prescribe that we should not mislead traders, even if it means not being able to show sexy plots. As the great Feynman said: You should not fool the layman when you're talking as a scientist. You can readily appreciate the fantasy plot of "c4", the thinnest line in black, by comparing its supposedly non-repainting behavior between historical bars and realtime bars. After updating—by miracle—as early as the wide yellow line that is repainting, it suddenly moves in a more realistic place when the script is running in realtime, in synch with our non-repainting lines. The "c5" version does not plot on the chart, but it displays in the Data Window. It is even worse than "c4" in that it also updates magically early on historical bars, but goes on to evaluate like the repainting yellow line in realtime, except one bar late. Data Window The Data Window shows the values of the chart's plots, then the values of both the inside and outside offsets used in our calculations, so you can see them change bar by bar. Notice their differences between historical and elapsed realtime bars, and the realtime bar itself. If you do not know about the Data Window, have a look at this essential tool for Pine coders in the Pine User Manual's page on Debugging . The conditional expressions used to calculate the offsets may seem tortuous but their objective is quite simple. When repainting is on, we use this form, so with no offset on all bars: security(ticker, i_timeframe, i_source ) // which is equivalent to: security(ticker, i_timeframe, i_source) When repainting is off, we use two different and inverted offsets on historical bars and the realtime bar: // Historical bars: security(ticker, i_timeframe, i_source ) // Realtime bar (and thus, elapsed realtime bars): security(ticker, i_timeframe, i_source ) The offsets in the first line show how we prevent repainting on historical bars without the need for the `lookahead` parameter. We use the value of the function call on the chart's previous bar. Since values between the repainting and non-repainting versions only differ on the timeframe's last bar, we can use the previous value so that the update only occurs on the timeframe's first bar, as it will in realtime when not repainting. In the realtime bar, we use the second call, where the offsets are inverted. This is because if we used the first call in realtime, we would be fetching the value of the repainting function on the previous bar, so the close of the last bar. What we want, instead, is the data from the previous, higher timeframe bar , which has elapsed and is confirmed, and thus will not change throughout realtime bars, except on the first constituent chart bar belonging to a new higher timeframe. After the offsets, the Data Window shows values for the `barstate.*` variables we use in our calculations. █  NOTES Why are we revisiting security()  ? For four reasons:  1 — We were seeing coders misuse our `f_secureSecurity()` function presented in How to avoid repainting when using security() .    Some novice coders were modifying the offset used with the history-referencing operator in the function, making it zero instead of one,    which to our horror, caused look-ahead bias when used with `lookahead = barmerge.lookahead_on`.    We wanted to present a safer function which avoids introducing the dreaded "lookahead" in the scripts of unsuspecting coders.  2 — The popularity of security() in screener-type scripts where coders need to use the full 40 calls allowed per script made us want to propose    a solid method of allowing coders to offer a repainting/no-repainting choice to their script users with only one security() call.  3 — We wanted to explain why some alternatives we see circulating are inadequate and produce misleading behavior.  4 — Our previous publication on security() focused on how to avoid repainting, yet many other considerations worthy of attention are not related to repainting. Handling tuples When sending function calls that return tuples with security() , our `f_security()` function will not work because Pine does not allow us to use the history-referencing operator with tuple return values. The solution is to integrate the inside offset to your function's arguments, use it to offset the results the function is returning, and then add the outside offset in a reassignment of the tuple variables, after security() returns its values to the script, as we do in our "c2" example. Does it repaint? We're pretty sure Wilder was not asked very often if RSI repainted. Why? Because it wasn't in fashion—and largely unnecessary—to ask that sort of question in the 80's. Many traders back then used daily charts only, and indicator values were calculated at the day's close, so everybody knew what they were getting. Additionally, indicator values were calculated by generally reputable outfits or traders themselves, so data was pretty reliable. Today, almost anybody can write a simple indicator, and the programming languages used to write them are complex enough for some coders lacking the caution, know-how or ethics of the best professional coders, to get in over their heads and produce code that does not work the way they think it does. As we hope to have clearly demonstrated, traders do have legitimate cause to ask if MTF scripts repaint or not when authors do not specify it in their script's description. ► We recommend that authors always use our `f_security()` with `false` as the last argument to avoid repainting when fetching data dependent on OHLCV information. This is the only way to obtain reliable HTF data. If you want to offer users a choice, make non-repainting mode the default, so that if users choose repainting, it will be their responsibility. Non-repainting security() calls are also the only way for scripts to show historical behavior that matches the script's realtime behavior, so you are not misleading traders. Additionally, non-repainting HTF data is the only way that non-repainting alerts can be configured on MTF scripts, as users of MTF scripts cannot prevent their alerts from repainting by simply configuring them to trigger on the bar's close. Data feeds A chart at one timeframe is made up of multiple feeds that mesh seamlessly to form one chart. Historical bars can use one feed, and the realtime bar another, which brokers/exchanges can sometimes update retroactively so that elapsed realtime bars will reappear with very slight modifications when the browser's tab is refreshed. Intraday and daily chart prices also very often originate from different feeds supplied by brokers/exchanges. That is why security() calls at higher timeframes may be using a completely different feed than the chart, and explains why the daily high value, for example, can vary between timeframes. Volume information can also vary considerably between intraday and daily feeds in markets like stocks, because more volume information becomes available at the end of day. It is thus expected behavior—and not a bug—to see data variations between timeframes. Another point to keep in mind concerning feeds it that when you are using a repainting security() plot in realtime, you will sometimes see discrepancies between its plot and the realtime bars. An artefact revealing these inconsistencies can be seen when security() plots sometimes skip a realtime chart bar during periods of high market activity. This occurs because of races between the chart and the security() feeds, which are being monitored by independent, concurrent processes. A blue arrow on the chart indicates such an occurrence. This is another cause of repainting, where realtime bar-building logic can produce different outcomes on one closing price. It is also another argument supporting our recommendation to use non-repainting data. Alternatives There is an alternative to using security() in some conditions. If all you need are OHLC prices of a higher timeframe, you can use a technique like the one Duyck demonstrates in his security free MTF example - JD script. It has the great advantage of displaying actual repainting values on historical bars, which mimic the code's behavior in the realtime bar—or at least on elapsed realtime bars, contrary to a repainting security() plot. It has the disadvantage of using the current chart's TF data feed prices, whereas higher timeframe data feeds may contain different and more reliable prices when they are compiled at the end of the day. In its current state, it also does not allow for a repainting/no-repainting choice. When `lookahead` is useful When retrieving non-price data, or in special cases, for experiments, it can be useful to use `lookahead`. One example is our Backtesting on Non-Standard Charts: Caution! script where we are fetching prices of standard chart bars from non-standard charts. Warning users Normal use of security() dictates that it only be used at timeframes equal to or higher than the chart's. To prevent users from inadvertently using your script in contexts where it will not produce expected behavior, it is good practice to warn them when their chart is on a higher timeframe than the one in the script's "Timeframe" field. Our `f_tfReminderAndErrorCheck()` function in this script does that. It can also print a reminder of the higher timeframe. It uses one security() call. Intrabar timeframes security() is not supported by TradingView when used with timeframes lower than the chart's. While it is still possible to use security() at intrabar timeframes, it then behaves differently. If no care is taken to send a function specifically written to handle the successive intrabars, security() will return the value of the last intrabar in the chart's timeframe, so the last 1H bar in the current 1D bar, if called at "60" from a "D" chart timeframe. If you are an advanced coder, see our FAQ entry on the techniques involved in processing intrabar timeframes. Using intrabar timeframes comes with important limitations, which you must understand and explain to traders if you choose to make scripts using the technique available to others. Special care should also be taken to thoroughly test this type of script. Novice coders should refrain from getting involved in this. █  TERMINOLOGY Timeframe Timeframe , interval and resolution are all being used to name the concept of timeframe. We have, in the past, used "timeframe" and "resolution" more or less interchangeably. Recently, members from the Pine and PineCoders team have decided to settle on "timeframe", so from hereon we will be sticking to that term. Multi-timeframe (MTF) Some coders use "multi-timeframe" or "MTF" to name what are in fact "multi-period" calculations, as when they use MAs of progressively longer periods. We consider that a misleading use of "multi-timeframe", which should be reserved for code using calculations actually made from another timeframe's context and using security() , safe for scripts like Duyck's one mentioned earlier, or TradingView's Relative  Volume  at  Time , which use a user-selected timeframe as an anchor to reset calculations. Calculations made at the chart's timeframe by varying the period of MAs or other rolling window calculations should be called "multi-period", and "MTF-anchored" could be used for scripts that reset calculations on timeframe boundaries. Colophon Our script was written using the PineCoders Coding Conventions for Pine . The description was formatted using the techniques explained in the How We Write and Format Script Descriptions PineCoders publication. Snippets were lifted from our MTF Selection Framework , then massaged to create the `f_tfReminderAndErrorCheck()` function. █  THANKS Thanks to apozdnyakov for his help with the innards of security() . Thanks to bmistiaen for proofreading our description. Look first. Then leap.
Pine Script™ indicator
by PineCoders
60
Waindrops [Makit0]█  OVERALL Plot waindrops (custom volume profiles) on user defined periods, for each period you get high and low, it slices each period in half to get independent vwap, volume profile and the volume traded per price at each half. It works on intraday charts only, up to 720m (12H). It can plot balanced or unbalanced waindrops, and volume profiles up to 24H sessions. As example you can setup unbalanced periods to get independent volume profiles for the overnight and cash sessions on the futures market, or 24H periods to get the full session volume profile of EURUSD The purpose of this indicator is twofold: 1 — from a Chartist point of view, to have an indicator which displays the volume in a more readable way 2 — from a Pine Coder point of view, to have an example of use for two very powerful tools on Pine Script:    • the recently updated drawing limit to 500 (from 50)    • the recently ability to use drawings arrays (lines and labels) If you are new to Pine Script and you are learning how to code, I hope you read all the code and comments on this indicator, all is designed for you, the variables and functions names, the sometimes too big explanations, the overall structure of the code, all is intended as an example on how to code in Pine Script a specific indicator from a very good specification in form of white paper If you wanna learn Pine Script form scratch just start HERE In case you have any kind of problem with Pine Script please use some of the awesome resources at our disposal: USRMAN , REFMAN , AWESOMENESS , MAGIC █  FEATURES Waindrops are a different way of seeing the volume and price plotted in a chart, its a volume profile indicator where you can see the volume of each price level plotted as a vertical histogram for each half of a custom period. By default the period is 60 so it plots an independent volume profile each 30m You can think of each waindrop as an user defined candlestick or bar with four key values:  • high of the period  • low of the period  • left vwap (volume weighted average price of the first half period)  • right vwap (volume weighted average price of the second half period) The waindrop can have 3 different colors (configurable by the user):  • GREEN: when the right vwap is higher than the left vwap (bullish sentiment )  • RED: when the right vwap is lower than the left vwap (bearish sentiment )  • BLUE: when the right vwap is equal than the left vwap ( neutral sentiment ) KEY FEATURES  • Help menu  • Custom periods  • Central bars  • Left/Right VWAPs  • Custom central bars and vwaps: color and pixels  • Highly configurable volume histogram: execution window, ticks, pixels, color, update frequency and fine tuning the neutral meaning  • Volume labels with custom size and color  • Tracking price dot to be able to see the current price when you hide your default candlesticks or bars █  SETTINGS Click here or set any impar period to see the HELP INFO : show the HELP INFO, if it is activated the indicator will not plot PERIOD SIZE (max 2880 min) : waindrop size in minutes, default 60, max 2880 to allow the first half of a 48H period as a full session volume profile BARS : show the central and vwap bars, default true    Central bars : show the central bars, default true    VWAP bars : show the left and right vwap bars, default true    Bars pixels : width of the bars in pixels, default 2    Bars color mode : bars color behavior    • BARS : gets the color from the 'Bars color' option on the settings panel    • HISTOGRAM : gets the color from the Bearish/Bullish/Neutral Histogram color options from the settings panel    Bars color : color for the central and vwap bars, default white HISTOGRAM show the volume histogram, default true    Execution window (x24H) : last 24H periods where the volume funcionality will be plotted, default 5    Ticks per bar (max 50) : width in ticks of each histogram bar, default 2    Updates per period : number of times the histogram will update    • ONE : update at the last bar of the period    • TWO : update at the last bar of each half period    • FOUR : slice the period in 4 quarters and updates at the last bar of each of them    • EACH BAR : updates at the close of each bar    Pixels per bar : width in pixels of each histogram bar, default 4    Neutral Treshold (ticks) : delta in ticks between left and right vwaps to identify a waindrop as neutral, default 0    Bearish Histogram color : histogram color when right vwap is lower than left vwap, default red    Bullish Histogram color : histogram color when right vwap is higher than left vwap, default green    Neutral Histogram color : histogram color when the delta between right and left vwaps is equal or lower than the Neutral treshold, default blue VOLUME LABELS : show volume labels    Volume labels color : color for the volume labels, default white    Volume Labels size : text size for the volume labels, choose between AUTO, TINY, SMALL, NORMAL or LARGE, default TINY TRACK PRICE : show a yellow ball tracking the last price, default true █  LIMITS This indicator only works on intraday charts (minutes only) up to 12H (720m), the lower chart timeframe you can use is 1m This indicator needs price, time and volume to work, it will not work on an index (there is no volume), the execution will not be allowed The histogram (volume profile) can be plotted on 24H sessions as limit but you can plot several 24H sessions █  ERRORS AND PERFORMANCE Depending on the choosed settings, the script performance will be highly affected and it will experience errors Two of the more common errors it can throw are:  • Calculation takes too long to execute  • Loop takes too long The indicator performance is highly related to the underlying volatility (tick wise), the script takes each candlestick or bar and for each tick in it stores the price and volume, if the ticker in your chart has thousands and thousands of ticks per bar the indicator will throw an error for sure, it can not calculate in time such amount of ticks. What all of that means? Simply put, this will throw error on the BITCOIN pair BTCUSD (high volatility with tick size 0.01) because it has too many ticks per bar, but lucky you it will work just fine on the futures contract BTC1! (tick size 5) because it has a lot less ticks per bar There are some options you can fine tune to boost the script performance, the more demanding option in terms of resources consumption is Updates per period , by default is maxed out so lowering this setting will improve the performance in a high way. If you wanna know more about how to improve the script performance, read the HELP INFO accessible from the settings panel █  HOW-TO SETUP The basic parameters to adjust are Period size , Ticks per bar and Pixels per bar  • Period size is the main setting, defines the waindrop size, to get a better looking histogram set bigger period and smaller chart timeframe  • Ticks per bar is the tricky one, adjust it differently for each underlying (ticker) volatility wise, for some you will need a low value, for others a high one.    To get a more accurate histogram set it as lower as you can (min value is 1)  • Pixels per bar allows you to adjust the width of each histogram bar, with it you can adjust the blank space between them or allow overlaping You must play with these three parameters until you obtain the desired histogram: smoother, sharper, etc... These are some of the different kind of charts you can setup thru the settings:  • Balanced Waindrops (default): charts with waindrops where the two halfs are of same size.    This is the default chart, just select a period (30m, 60m, 120m, 240m, pick your poison), adjust the histogram ticks and pixels and watch  • Unbalanced Waindrops: chart with waindrops where the two halfs are of different sizes.    Do you trade futures and want to plot a waindrop with the first half for the overnight session and the second half for the cash session? you got it;    just adjust the period to 1860 for any CME ticker (like ES1! for example) adjust the histogram ticks and pixels and watch  • Full Session Volume Profile: chart with waindrops where only the first half plots.    Do you use Volume profile to analize the market? Lucky you, now you can trick this one to plot it, just try a period of 780 on SPY, 2760 on ES1!, or 2880 on EURUSD    remember to adjust the histogram ticks and pixels for each underlying  • Only Bars: charts with only central and vwap bars plotted, simply deactivate the histogram and volume labels  • Only Histogram: charts with only the histogram plotted (volume profile charts), simply deactivate the bars and volume labels  • Only Volume: charts with only the raw volume numbers plotted, simply deactivate the bars and histogram If you wanna know more about custom full session periods for different asset classes, read the HELP INFO accessible from the settings panel EXAMPLES Full Session Volume Profile on MES 5m chart: Full Session Unbalanced Waindrop on MNQ 2m chart (left side Overnight session, right side Cash Session): The following examples will have the exact same charts but on four different tickers representing a futures contract, a forex pair, an etf and a stock. We are doing this to be able to see the different parameters we need for plotting the same kind of chart on different assets The chart composition is as follows:  • Left side: Volume Labels chart (period 10)  • Upper Right side: Waindrops (period 60)  • Lower Right side: Full Session Volume Profile The first example will specify the main parameters, the rest of the charts will have only the differences MES :  • Left: Period size: 10, Bars: uncheck, Histogram: uncheck, Execution window: 1, Ticks per bar: 2, Updates per period: EACH BAR,    Pixels per bar: 4, Volume labels: check, Track price: check  • Upper Right: Period size: 60, Bars: check, Bars color mode: HISTOGRAM, Histogram: check, Execution window: 2, Ticks per bar: 2,    Updates per period: EACH BAR, Pixels per bar: 4, Volume labels: uncheck, Track price: check  • Lower Right: Period size: 2760, Bars: uncheck, Histogram: check, Execution window: 1, Ticks per bar: 1, Updates per period: EACH BAR,    Pixels per bar: 2, Volume labels: uncheck, Track price: check EURUSD :  • Upper Right: Ticks per bar: 10  • Lower Right: Period size: 2880, Ticks per bar: 1, Pixels per bar: 1 SPY :  • Left: Ticks per bar: 3  • Upper Right: Ticks per bar: 5, Pixels per bar: 3  • Lower Right: Period size: 780, Ticks per bar: 2, Pixels per bar: 2 AAPL :  • Left: Ticks per bar: 2  • Upper Right: Ticks per bar: 6, Pixels per bar: 3  • Lower Right: Period size: 780, Ticks per bar: 1, Pixels per bar: 2 █  THANKS TO PineCoders for all they do, all the tools and help they provide and their involvement in making a better community scarf for the idea of coding a waindrops like indicator, I did not know something like that existed at all All the Pine Coders, Pine Pros and Pine Wizards, people who share their work and knowledge for the sake of it and helping others, I'm very grateful indeed I'm learning at each step of the way from you all, thanks for this awesome community; Opensource and shared knowledge: this is the way! (said with canned voice from inside my helmet :D) █  NOTE This description was formatted following THIS guidelines ═════════════════════════════════════════════════════════════════════════ I sincerely hope you enjoy reading and using this work as much as I enjoyed developing it :D GOOD LUCK AND HAPPY TRADING!
Pine Script™ indicator
by makit0
107
CVD - Cumulative Volume Delta (Chart)█   OVERVIEW This indicator displays cumulative ​volume delta (​CVD) as an on-chart oscillator. It uses intrabar analysis to obtain more precise ​volume delta information compared to methods that only use the chart's timeframe. The core concepts in this script come from our first ​ CVD indicator , which displays CVD​ values as plot candles in a separate indicator pane. In this script, CV​D values are scaled according to price ranges and represented on the main chart pane. █   CONCEPTS Bar polarity Bar polarity refers to the position of the close price relative to the open price. In other words, bar polarity is the direction of price change. Intrabars Intrabars are chart bars at a lower timeframe than the chart's. Each 1H chart bar of a 24x7 market will, for example, usually contain 60 bars at the lower timeframe of 1min, provided there was market activity during each minute of the hour. Mining information from intrabars can be useful in that it offers traders visibility on the activity inside a chart bar. Lower timeframes (LTFs) A lower timeframe is a timeframe that is smaller than the chart's timeframe. This script utilizes a LTF to analyze intrabars, or price changes within a chart bar. The lower the ​LTF, the more intrabars are analyzed, but the less chart bars can display information due to the limited number of intrabars that can be analyzed. Volume delta Volume delta is a measure that separates ​volume​ into "up" and "down" parts, then takes the difference to estimate the net demand for the asset. This approach gives traders a more detailed insight when analyzing volume​ and market sentiment. There are several methods for determining whether an asset's volume​ belongs in the "up" or "down" category. Some indicators, such as On Balance Volume​ and the Klinger Oscillator , use the change in price between bars to assign ​volume​ values to the appropriate category. Others, such as Chaikin Money Flow , make assumptions based on open, high, low, and close prices. The most accurate method involves using tick data to determine whether each transaction occurred at the bid or ask price and assigning the ​volume​ value to the appropriate category accordingly. However, this method requires a large amount of data on historical bars, which can limit the historical depth of charts and the number of symbols for which tick data is available. In the context where historical tick data is not yet available on TradingView, intrabar analysis is the most precise technique to calculate ​volume delta on historical bars on our charts. This indicator uses intrabar analysis to achieve a compromise between simplicity and accuracy in calculating ​volume delta on historical bars. Our Volume Profile indicators use it as well. Other ​volume delta indicators in our Community Scripts , such as the Realtime 5D Profile , use real-time chart updates to achieve more precise ​volume delta calculations. However, these indicators aren't suitable for analyzing historical bars since they only work for real-time analysis. This is the logic we use to assign intrabar ​volume to the "up" or "down" category:  • If the intrabar's open and close values are different, their relative position is used.  • If the intrabar's open and close values are the same, the difference between the intrabar's close and the previous intrabar's close is used.  • As a last resort, when there is no movement during an intrabar and it closes at the same price as the previous intrabar, the last known polarity is used. Once all intrabars comprising a chart bar are analyzed, we calculate the net difference between "up" and "down" intrabar volume​ to produce the volume​ delta for the chart bar. █   FEATURES CVD resets The "cumulative" part of the indicator's name stems from the fact that calculations accumulate during a period of time. By periodically resetting the volume​ delta accumulation, we can analyze the progression of ​volume delta across manageable chunks, which is often more useful than looking at ​volume delta accumulated from the beginning of a chart's history. You can configure the reset period using the "CVD Resets" input, which offers the following selections:  • None : Calculations do not reset.  • On a fixed higher timeframe : Calculations reset on the higher timeframe you select in the "Fixed higher timeframe" field.  • At a fixed time that you specify.  • At the beginning of the regular session .  • On trend changes : Calculations reset on the direction change of either the Aroon indicator, Parabolic SAR , or Supertrend .  • On a stepped higher timeframe : Calculations reset on a higher timeframe automatically stepped using the chart's timeframe and following these rules: Chart TF ​HTF < 1min 1H < 3H 1D <= 12H 1W < 1W 1M >= 1W 1Y Specifying intrabar precision Ten options are included in the script to control the number of intrabars used per chart bar for calculations. The greater the number of intrabars per chart bar, the fewer chart bars can be analyzed. The first five options allow users to specify the approximate amount of chart bars to be covered:  • Least Precise (Most chart bars) : Covers all chart bars by dividing the current timeframe by four.   This ensures the highest level of intrabar precision while achieving complete coverage for the dataset.  • Less Precise (Some chart bars) & More Precise (Less chart bars) : These options calculate a stepped ​LTF in relation to the current chart's timeframe.  • Very precise (2min intrabars) : Uses the second highest quantity of intrabars possible with the 2min ​LTF.  • Most precise (1min intrabars) : Uses the maximum quantity of intrabars possible with the 1min ​LTF. The stepped lower timeframe for "Less Precise" and "More Precise" options is calculated from the current chart's timeframe as follows: Chart Timeframe Lower Timeframe Less Precise More Precise < 1hr 1min 1min < 1D 15min 1min < 1W ​2hr​ 30min > 1W 1D 60min The last five options allow users to specify an approximate fixed number of intrabars to analyze per chart bar. The available choices are 12, 24, 50, 100, and 250. The script will calculate the LTF​ which most closely approximates the specified number of intrabars per chart bar. Keep in mind that due to factors such as the length of a ticker's sessions and rounding of the LTF​, it is not always possible to produce the exact number specified. However, the script will do its best to get as close to the value as possible. As there is a limit to the number of intrabars that can be analyzed by a script, a tradeoff occurs between the number of intrabars analyzed per chart bar and the chart bars for which calculations are possible. Display This script displays raw or cumulative volume​ delta values on the chart as either line or histogram oscillator zones scaled according to the price chart, allowing traders to visualize volume​ activity on each bar or cumulatively over time. The indicator's background shows where CVD​ resets occur, demarcating the beginning of new zones. The vertical axis of each oscillator zone is scaled relative to the one with the highest price range, and the oscillator values are scaled relative to the highest volume​ delta. A vertical offset is applied to each oscillator zone so that the highest oscillator value aligns with the lowest price. This method ensures an accurate, intuitive visual comparison of volume​ activity within zones, as the scale is consistent across the chart, and oscillator values sit below prices. The vertical scale of oscillator zones can be adjusted using the "Zone Height" input in the script settings. This script displays labels at the highest and lowest oscillator values in each zone, which can be enabled using the "Hi/Lo Labels" input in the "Visuals" section of the script settings. Additionally, the oscillator's value on a chart bar is displayed as a tooltip when a user hovers over the bar, which can be enabled using the "Value Tooltips" input. Divergences occur when the polarity of ​volume delta does not match that of the chart bar. The script displays divergences as bar colors and background colors that can be enabled using the "Color bars on divergences" and "Color background on divergences" inputs. An information box in the lower-left corner of the indicator displays the HTF used for resets, the ​LTF used for intrabars, the average quantity of intrabars per chart bar, and the number of chart bars for which there is LTF data. This is enabled using the "Show information box" input in the "Visuals" section of the script settings. FOR Pine Script™ CODERS  • This script utilizes `ltf()` and `ltfStats()` from the lower_tf library.   The `ltf()` function determines the appropriate lower timeframe from the selected calculation mode and chart timeframe, and returns it in a format that can be used with request.security_lower_tf() .   The `ltfStats()` function, on the other hand, is used to compute and display statistical information about the lower timeframe in an information box.  • The script utilizes display.data_window and display.status_line to restrict the display of certain plots.   These new built-ins allow coders to fine-tune where a script’s plot values are displayed.  • The newly added session.isfirstbar_regular built-in allows for resetting the ​CVD segments at the start of the regular session.  • The VisibleChart library developed by our resident PineCoders team leverages the chart.left_visible_bar_time and chart.right_visible_bar_time variables to optimize the performance of this script.   These variables identify the opening time of the leftmost and rightmost visible bars on the chart, allowing the script to recalculate and draw objects only within the range of visible bars as the user scrolls.   This functionality also enables the scaling of the oscillator zones.   These variables are just a couple of the many new built-ins available in the chart.* namespace.   For more information, check out this blog post or look them up by typing "chart." in the Pine Script™ Reference Manual .  • Our ta library has undergone significant updates recently, including the incorporation of the `aroon()` indicator used as a method for resetting ​CVD segments within this script.   Revisit the library to see more of the newly added content! Look first. Then leap.
Pine Script™ indicator
by TradingView
49
Delta Volume Columns Pro [LucF]█  OVERVIEW This indicator displays volume​​ delta information calculated with intrabar inspection on historical bars, and feed updates when running in realtime. It is designed to run in a pane and can display either stacked buy/sell volume​ columns or a signal line which can be calculated and displayed in many different ways. Five different models are offered to reveal different characteristics of the calculated volume​ delta information. Many options are offered to visualize the calculations, giving you much leeway in morphing the indicator's visuals to suit your needs. If you value delta volume​ information, I hope you will find the time required to master Delta Volume​ Columns Pro well worth the investment. I am confident that if you combine a proper understanding of the indicator's information with an intimate knowledge of the volume​ idiosyncrasies on the markets you trade, you can extract useful market intelligence using this tool. █  WARNINGS 1. The indicator only works on markets where volume​ information is available,   Please validate that your symbol's feed carries volume​ information before asking me why the indicator doesn't plot values. 2. When you refresh your chart or re-execute the script on the chart, the indicator will repaint because elapsed realtime bars will then recalculate as historical bars. 3. Because the indicator uses different modes of calculation on historical and realtime bars, it's critical that you understand the differences between them. Details are provided further down. 4. Calculations using intrabar inspection on historical bars can only be done from some chart timeframes. See further down for a list of supported timeframes.   If the chart's timeframe is not supported, no historical volume​ delta will display. █  CONCEPTS Chart bars Three different types of bars are used in charts:  1. Historical bars are bars that have already closed when the script executes on them.  2. The realtime bar is the current, incomplete bar where a script is running on an open market. There is only one active realtime bar on your chart at any given time.    The realtime bar is where alerts trigger.  3. Elapsed realtime bars are bars that were calculated when they were realtime bars but have since closed.    When a script re-executes on a chart because the browser tab is refreshed or some of its inputs are changed, elapsed realtime bars are recalculated as historical bars. Why does this indicator use two modes of calculation? Historical bars on TradingView charts contain OHLCV data only, which is insufficient to calculate volume​ delta on them with any level of precision. To mine more detailed information from those bars we look at intrabars , i.e., bars from a smaller timeframe (we call it the intrabar timeframe ) that are contained in one chart bar. If your chart Is running at 1D on a 24x7 market for example, most 1D chart bars will contain 24 underlying 1H bars in their dilation. On historical bars, this indicator looks at those intrabars to amass volume​ delta information. If the intrabar is up, its volume​ goes in the Buy bin, and inversely for the Sell bin. When price does not move on an intrabar, the polarity of the last known movement is used to determine in which bin its volume​ goes. In realtime, we have access to price and volume​ change for each update of the chart. Because a 1D chart bar can be updated tens of thousands of times during the day, volume​ delta calculations on those updates is much more precise. This precision, however, comes at a price:  — The script must be running on the chart for it to keep calculating in realtime.  — If you refresh your chart you will lose all accumulated realtime calculations on elapsed realtime bars, and the realtime bar.   Elapsed realtime bars will recalculate as historical bars, i.e., using intrabar inspection, and the realtime bar's calculations will reset.   When the script recalculates elapsed realtime bars as historical bars, the values on those bars will change, which means the script repaints in those conditions.  — When the indicator first calculates on a chart containing an incomplete realtime bar, it will count ALL the existing volume​ on the bar as Buy or Sell volume​,   depending on the polarity of the bar at that point. This will skew calculations for that first bar. Scripts have no access to the history of a realtime bar's previous updates,   and intrabar inspection cannot be used on realtime bars, so this is the only to go about this.  — Even if alerts only trigger upon confirmation of their conditions after the realtime bar closes, they are repainting alerts   because they would perhaps not have calculated the same way using intrabar inspection.  — On markets like stocks that often have different EOD​ and intraday feeds and volume​ information,   the volume's scale may not be the same for the realtime bar if your chart is at 1D, for example,   and the indicator is using an intraday timeframe to calculate on historical bars.  — Any chart timeframe can be used in realtime mode, but plots that include moving averages in their calculations may require many elapsed realtime bars before they can calculate.   You might prefer drastically reducing the periods of the moving averages, or using the volume​ columns mode, which displays instant values, instead of the line. Volume Delta Balances This indicator uses a variety of methods to evaluate five volume​ delta balances and derive other values from those balances. The five balances are: 1 — On Bar Balance : This is the only balance using instant values; it is simply the subtraction of the Sell volume​ from the Buy volume​ on the bar. 2 — Average Balance : Calculates a distinct EMA for both the Buy and Sell volumes, and subtracts the Sell EMA from the Buy EMA. 3 — Momentum Balance : Starts by calculating, separately for both Buy and Sell volumes, the difference between the same EMAs used in "Average Balance" and   an SMA of double the period used for the "Average Balance" EMAs. The difference for the Sell side is subtracted from the difference for the Buy side,   and an RSI of that value is calculated and brought over the −50/+50 scale. 4 — Relative Balance : The reference values used in the calculation are the Buy and Sell EMAs used in the "Average Balance".   From those, we calculate two intermediate values using how much the instant Buy and Sell volumes on the bar exceed their respective EMA — but with a twist.   If the bar's Buy volume​ does not exceed the EMA of Buy volume​, a zero value is used. The same goes for the Sell volume​ with the EMA of Sell volume​.   Once we have our two intermediate values for the Buy and Sell volumes exceeding their respective MA, we subtract them. The final "Relative Balance" value is an ALMA of that subtraction.   The rationale behind using zero values when the bar's Buy/Sell volume​ does not exceed its EMA is to only take into account the more significant volume​.   If both instant volume​ values exceed their MA, then the difference between the two is the signal's value.   The signal is called "relative" because the intermediate values are the difference between the instant Buy/Sell volumes and their respective MA.   This balance flatlines when the bar's Buy/Sell volumes do not exceed their EMAs, which makes it useful to spot areas where trader interest dwindles, such as consolidations.   The smaller the period of the final value's ALMA, the more easily you will see the balance flatline. These flat zones should be considered no-trade zones. 5 — Percent Balance : This balance is the ALMA of the ratio of the "On Bar Balance" value, i.e., the volume​ delta balance on the bar (which can be positive or negative),   over the total volume for that bar. From the balances and marker conditions, two more values are calculated: 1 — Marker Bias : It sums the up/down (+1/‒1) occurrences of the markers 1 to 4 over a period you define, so it ranges from −4 to +4, times the period.   Its calculation will depend on the modes used to calculate markers 3 and 4. 2 — Combined Balances : This is the sum of the bull/bear (+1/−1) states of each of the five balances, so it ranges from −5 to +5. █  FEATURES The indicator has two main modes of operation: Columns and Line . Columns • In Columns mode you can display stacked Buy/Sell volume​ columns. • The buy section always appears above the centerline, the sell section below. • The top and bottom sections can be colored independently using eight different methods. • The EMAs of the Buy/Sell values can be displayed (these are the same EMAs used to calculate the "Average Balance"). Line • Displays one of seven signals: the five balances or one of two complementary values, i.e., the "Marker Bias" or the "Combined Balances". • You can color the line and its fill using independent calculation modes to pack more information in the display.  You can thus appraise the state of 3 different values using the line itself, its color and the color of its fill. • A "Divergence Levels" feature will use the line to automatically draw expanding levels on divergence events. Default settings Using the indicator's default settings, this is the information displayed: • The line is calculated on the "Average Balance". • The line's color is determined by the bull/bear state of the "Percent Balance". • The line's fill gradient is determined by the advances/declines of the "Momentum Balance". • The orange divergence dots are calculated using discrepancies between the polarity of the "On Bar Balance" and the chart's bar. • The divergence levels are determined using the line's level when a divergence occurs. • The background's fill gradient is calculated on advances/declines of the "Marker Bias". • The chart bars are colored using advances/declines of the "Relative Balance". Divergences are shown in orange. • The intrabar timeframe is automatically determined from the chart's timeframe so that a minimum of 50 intrabars are used to calculate volume​ delta on historical bars. Alerts The configuration of the marker conditions explained further is what determines the conditions that will trigger alerts created from this script. Note that simply selecting the display of markers does not create alerts. To create an alert on this script, you must use ALT-A from the chart. You can create multiple alerts triggering on different conditions from this same script; simply configure the markers so they define the trigger conditions for each alert before creating the alert. The configuration of the script's inputs is saved with the alert, so from then on you can change them without affecting the alert. Alert messages will mention the marker(s) that triggered the specific alert event. Keep in mind, when creating alerts on small chart timeframes, that discrepancies between alert triggers and markers displayed on your chart are to be expected. This is because the alert and your chart are running two distinct instances of the indicator on different servers and different feeds. Also keep in mind that while alerts only trigger on confirmed conditions, they are calculated using realtime calculation mode, which entails that if you refresh your chart and elapsed realtime bars recalculate as historical bars using intrabar inspection, markers will not appear in the same places they appeared in realtime. So it's important to understand that even though the alert conditions are confirmed when they trigger, these alerts will repaint. Let's go through the sections of the script's inputs. Columns The size of the Buy/Sell columns always represents their respective importance on the bar, but the coloring mode for tops and bottoms is independent. The default setup uses a standard coloring mode where the Buy/Sell columns are always in the bull/bear color with a higher intensity for the winning side. Seven other coloring modes allow you to pack more information in the columns. When choosing to color the top columns using a bull/bear gradient on "Average Balance", for example, you will have bull/bear colored tops. In order for the color of the bottom columns to continue to show the instant bar balance, you can then choose the "On Bar Balance — Dual Solid Colors" coloring mode to make those bars the color of the winning side for that bar. You can display the averages of the Buy and Sell columns. If you do, its coloring is controlled through the "Line" and "Line fill" sections below. Line and Line fill You can select the calculation mode and the thickness of the line, and independent calculations to determine the line's color and fill. Zero Line The zero line can display dots when all five balances are bull/bear. Divergences You first select the detection mode. Divergences occur whenever the up/down direction of the signal does not match the up/down polarity of the bar. Divergences are used in three components of the indicator's visuals: the orange dot, colored chart bars, and to calculate the divergence levels on the line. The divergence levels are dynamic levels that automatically build from the line's values on divergence events. On consecutive divergences, the levels will expand, creating a channel. This implementation of the divergence levels corresponds to my view that divergences indicate anomalies, hesitations, points of uncertainty if you will. It precludes any attempt to identify a directional bias to divergences. Accordingly, the levels merely take note of divergence events and mark those points in time with levels. Traders then have a reference point from which they can evaluate further movement. The bull/bear/neutral colors used to plot the levels are also congruent with this view in that they are determined by the line's position relative to the levels, which is how I think divergences can be put to the most effective use. One of the coloring modes for the line's fill uses advances/declines in the line after divergence events. Background The background can show a bull/bear gradient on six different calculations. As with other gradients, you can adjust its brightness to make its importance proportional to how you use it in your analysis. Chart bars Chart bars can be colored using seven different methods. You have the option of emptying the body of bars where volume​ does not increase, as does my TLD indicator, and you can choose whether you want to show divergences. Intrabar Timeframe This is the intrabar timeframe that will be used to calculate volume​ delta using intrabar inspection on historical bars. You can choose between four modes. The three "Auto-steps" modes calculate, from the chart's timeframe, the intrabar timeframe where the said number of intrabars will make up the dilation of chart bars. Adjustments are made for non-24x7 markets. "Fixed" mode allows you to select the intrabar timeframe you want. Checking the "Show TF" box will display in the lower-right corner the intrabar timeframe used at any given moment. The proper selection of the intrabar timeframe is important. It must achieve maximal granularity to produce precise results while not unduly slowing down calculations, or worse, causing runtime errors. Note that historical depth will vary with the intrabar timeframe. The smaller the timeframe, the shallower historical plots you will be. Markers Markers appear when the required condition has been confirmed on a closed bar. The configuration of the markers when you create an alert is what determines when the alert will trigger. Five markers are available: • Balances Agreement : All five balances are either bullish​ or bearish​. • Double Bumps : A double bump is two consecutive up/down bars with +/‒ volume​​ delta, and rising Buy/Sell volume​ above its average. • Divergence confirmations : A divergence is confirmed up/down when the chosen balance is up/down on the previous bar when that bar was down/up, and this bar is up/down. • Balance Shifts : These are bull/bear transitions of the selected signal. • Marker Bias Shifts : Marker bias shifts occur when it crosses into bull/bear territory. Periods Allows control over the periods of the different moving averages used to calculate the balances. Volume​ Discrepancies Stock exchanges do not report the same volume​ for intraday and daily (or higher) resolutions. Other variations in how volume​ information is reported can also occur in other markets, namely Forex, where volume​ irregularities can even occur between different intraday timeframes. This will cause discrepancies between the total volume​ on the bar at the chart's timeframe, and the total volume​​ calculated by adding the volume​​ of the intrabars in that bar's dilation. This does not necessarily invalidate the volume​​ delta information calculated from intrabars, but it tells us that we are using partial volume​ data. A mechanism to detect chart vs intrabar timeframe volume​​ discrepancies is provided. It allows you to define a threshold percentage above which the background will indicate a difference has been detected. Other Settings You can control here the display of the gray dot reminder on realtime bars, and the display of error messages if you are using a chart timeframe that is not greater than the fixed intrabar timeframe, when you use that mode. Disabling the message can be useful if you only use realtime mode at chart timeframes that do not support intrabar inspection. █  RAMBLINGS On Volume​ Delta Volume​ is arguably the best complement to interpret price action, and I consider volume​ delta to be the most effective way of processing volume​ information. In periods of low-volatility price consolidations, volume​ will typically also be lower than normal, but slight imbalances in the trend of the buy/sell volume​ balance can sometimes help put early odds on the direction of the break from consolidation. Additionally, the progression of the volume​ imbalance can help determine the proximity of the breakout. I also find volume​ delta and the number of divergences very useful to evaluate the strength of trends. In trends, I am looking for "slow and steady", i.e., relatively low volatility​ and pauses where price action doesn't look like world affairs are being reassessed. In my personal mythology, this type of trend is often more resilient than high-volatility breakouts, especially when volume​ balance confirms the general agreement of traders signaled by the low-volatility usually accompanying this type of trend. The volume​ action on pauses will often help me decide between aggressively taking profits, tightening a stop or going for a longer-term movement. As for reversals, they generally occur in high-volatility areas where entering trades is more expensive and riskier. While the identification of counter-trend reversals fascinates many traders to no end, they represent poor opportunities in my view. Volume​ imbalances often precede reversals, but I prefer to use volume​ delta information to identify the areas following reversals where I can confirm them and make relatively low-cost entries with better odds. On "Buy/Sell" Volume Buying or selling volume​ are misnomers, as every unit of volume​ transacted is both bought and sold by two different traders. While this does not keep me from using the terms, there is no such thing as “buy only” or “sell only” volume​. Trader lingo is riddled with peculiarities. Divergences The divergence detection method used here relies on a difference between the direction of a signal and the polarity (up/down) of a chart bar. When using the default "On Bar Balance" to detect divergences, however, only the bar's volume​ delta is used. You may wonder how there can be divergences between buying/selling volume​ information and price movement on one bar. This will sometimes be due to the calculation's shortcomings, but divergences may also occur in instances where because of order book structure, it takes less volume​ to increase the price of an asset than it takes to decrease it. As usual, divergences are points of interest because they reveal imbalances, which may or may not become turning points. To your pattern-hungry brain, the divergences displayed by this indicator will — as they do on other indicators — appear to often indicate turnarounds. My opinion is that reality is generally quite sobering and I have no reliable information that would tend to prove otherwise. Exercise caution when using them. Consequently, I do not share the overwhelming enthusiasm of traders in identifying bullish​/bearish​ divergences. For me, the best course of action when a divergence occurs is to wait and see what happens from there. That is the rationale underlying how my divergence levels work; they take note of a signal's level when a divergence occurs, and it's the signal's behavior from that point on that determines if the post-divergence action is bullish​/bearish​. Superfluity In "The Bed of Procrustes", Nassim Nicholas Taleb writes: To bankrupt a fool, give him information . This indicator can display lots of information. While learning to use a new indicator inevitably requires an adaptation period where we put it through its paces and try out all its options, once you have become used to it and decide to adopt it, rigorously eliminate the components you don't use and configure the remaining ones so their visual prominence reflects their relative importance in your analysis. I tried to provide flexible options for traders to control this indicator's visuals for that exact reason — not for window dressing. █  LIMITATIONS • This script uses a special characteristic of the `security()` function allowing the inspection of intrabars — which is not officially supported by TradingView.  It has the advantage of permitting a more robust calculation of volume​ delta than other methods on historical bars, but also has its limits. • Intrabar inspection only works on some chart timeframes: 3, 5, 10, 15 and 30 minutes, 1, 2, 3, 4, 6, and 12 hours, 1 day, 1 week and 1 month.  The script’s code can be modified to run on other resolutions. • When the difference between the chart’s timeframe and the intrabar timeframe is too great, runtime errors will occur. The Auto-Steps selection mechanisms should avoid this. • All volume​ is not created equally. Its source, components, quality and reliability will vary considerably with sectors and instruments.  The higher the quality, the more reliably volume​ delta information can be used to guide your decisions.  You should make it your responsibility to understand the volume​ information provided in the data feeds you use. It will help you make the most of volume​ delta. █  NOTES For traders • The Data Window shows key values for the indicator. • While this indicator displays some of the same information calculated in my Delta Volume Columns ,  I have elected to make it a separate publication so that traders continue to have a simpler alternative available to them. Both code bases will continue to evolve separately. • All gradients used in this indicator determine their brightness intensities using advances/declines in the signal—not their relative position in a pre-determined scale. • Volume​ delta being relative, by nature, it is particularly well-suited to Forex markets, as it filters out quite elegantly the cyclical volume​ data characterizing the sector. If you are interested in volume​ delta, consider having a look at my other "Delta Volume" indicators: • Delta Volume Realtime Action displays realtime volume​ delta and tick information on the chart. • Delta Volume Candles builds volume​​ delta candles on the chart. • Delta Volume Columns is a simpler version of this indicator. For coders • I use the `f_c_gradientRelativePro()` from the PineCoders Color Gradient Framework to build my gradients.  This function has the advantage of allowing begin/end colors for both the bull and bear colors. It also allows us to define the number of steps allowed for each gradient.  I use this to modulate the gradients so they perform optimally on the combination of the signal used to calculate advances/declines,  but also the nature of the visual component the gradient applies to. I use fewer steps for choppy signals and when the gradient is used on discrete visual components  such as volume​ columns or chart bars. • I use the PineCoders Coding Conventions for Pine to write my scripts. • I used functions modified from the PineCoders MTF Selection Framework for the selection of timeframes. █  THANKS TO: — The devs from TradingView's Pine and other teams, and the PineCoders who collaborate with them. They are doing amazing work,  and much of what this indicator does could not be done without their recent improvements to Pine. — A guy called Kuan who commented on a Backtest Rookies presentation of their Volume Profile indicator using a `for` loop.  This indicator started from the intrabar inspection technique illustrated in Kuan's snippet. — theheirophant , my partner in the exploration of the sometimes weird abysses of `security()`’s behavior at intrabar timeframes. — midtownsk8rguy , my brilliant companion in mining the depths of Pine graphics.
Pine Script™ indicator
by LucF
120
Realtime Delta Volume Action [LucF]█  OVERVIEW This indicator displays on-chart, realtime, delta volume​ and delta ticks information for each bar. It aims to provide traders who trade price action on small timeframes with volume​ and tick information gathered as updates come in the chart's feed. It builds its own candles, which are optimized to display volume​ delta information. It only works in realtime. █  WARNING This script is intended for traders who can already profitably trade discretionary on small timeframes. The high cost in fees and the excitement of trading at small timeframes have ruined many newcomers to trading. While trading at small timeframes can work magic for adrenaline junkies in search of thrills rather than profits, I DO NOT recommend it to most traders. Only seasoned discretionary traders able to factor in the relatively high cost of such a trading practice can ever hope to take money out of markets in that type of environment, and I would venture​ they account for an infinitesimal percentage of traders. If you are a newcomer to trading, AVOID THIS TOOL AT ALL COSTS — unless you are interested in experimenting with the interpretation of volume​ delta combined with price action. No tool currently available on TradingView provides this type of close monitoring of volume​ delta information, but if you are not already trading small timeframes profitably, please do not let yourself become convinced that it is the missing piece you needed. Avoid becoming a sucker who only contributes by providing liquidity to markets. The information calculated by the indicator cannot be saved on charts, nor can it be recalculated from historical bars. If you refresh the chart or restart the script, the accumulated information will be lost. █  FEATURES Key values The script displays the following key values:  • Above the bar: ticks delta​ (DT​), the total ticks​ for the bar, the percentage of total ticks that DT​ represents (DT%)  • Below the bar: volume delta​ (DV​), the total volume​ for the bar, the percentage of total volume​ that DV​ represents (DV%). Candles Candles are composed of four components:  1. A top shaped like this: ┴, and a bottom shaped like this: ┬ (picture a normal Japanese candle without a body outline; the values used are the same).  2. The candle bodies are filled with the bull/bear color representing the polarity of DV​. The intensity of the body's color is determined by the DV% value.    When DV% is 100, the intensity of the fill is brightest. This plays well in interpreting the body colors, as the smaller, less significant DV% values will produce less vivid colors.  3. The bright-colored borders of the candle bodies occur on "strong bars", i.e., bars meeting the criteria selected in the script's inputs, which you can configure.  4. The POC line is a small horizontal line that appears to the left of the candle. It is the volume-weighted average of all price updates during the bar. Calculations This script monitors each realtime update of the chart's feed. It first determines if price has moved up or down since the last update. The polarity of the price change, in turn, determines the polarity of the volume​​ and tick for that specific update. If price does not move between consecutive updates, then the last known polarity is used. Using this method, we can calculate a running volume​ delta and ticks delta for the bar, which becomes the bar's final​ delta values when the bar closes (you can inspect values of elapsed realtime bars in the Data Window or the indicator's values). Note that these values will all reset if the script re-executes because of a change in inputs or a chart refresh. While this method of calculating is not perfect, it is by far the most precise way of calculating volume​ delta available on TradingView at the moment. Calculating more precise results would require scripts to have access to tick data from any chart timeframe. Charts at seconds timeframes do use exchange/broker ticks when the feeds you are using allow for it, and this indicator will run on them, but tick data is not yet available from higher timeframes. Also, note that the method used in this script is far superior to the intrabar inspection technique used on historical bars in my other "Delta Volume​" indicators. This is because volume​ and ticks delta here are calculated from many more realtime updates than the available intrabars in history. Unfortunately, the calculation method used here cannot be used on historical bars, where intrabar inspection remains, in my opinion, the optimal method. Inputs The script's inputs provide many ways to personalize all the components: what is displayed, the colors used to display the information, and the marker conditions. Tooltips provide details for many of the inputs; I leave their exploration to you. Markers Markers provide a way for you to identify the points of interest of your choice on the chart. You control the set of conditions that trigger each of the five available markers. You select conditions by entering, in the field for each marker, the number of each condition you want to include, separated by a comma. The conditions are:   1 —  The bar's polarity is up/dn​.   2 —  `close` rises/falls ("rises" means it is higher than its value on the previous bar).   3 —  DV's polarity is +/–.   4 —  DV% rises (↕).   5 —  POC rises/falls.   6 —  The quantity of realtime updates rises (↕).   7 —  DV​ > limit (You specify the limit in the inputs. Since DV​ can be +/–, DV– must be less than `–limit` for a short marker).   8 —  DV% > limit (↕).   9 —  DV+ rises for a long marker, DV– falls for a short.  10 —  Consecutive DV+/DV– on two bars.  11 —  Total volume rises (↕).  12 —  DT's polarity is +/–.  13 —  DT% rises (↕).  14 —  DT+ rises for a long marker, DT– falls for a short. Conditions showing the (↕) symbol do not have symmetrical states; they act more like filters. If you only include condition 4 in a marker's setup, for example, both long and short markers will trigger on bars where DV% rises. To trigger only long or short markers, you must add a condition providing directional differentiation, such as conditions 1 or 2. Accordingly, you would enter "1,4" or "2,4". For a marker to trigger, ALL the conditions you specified for it must be met. Long markers appear on the chart as "Mx▲" signs under the values displayed below candles. Short markers display "Mx▼" over the number of updates displayed above candles. The marker's number will replace the "x" in "Mx▲". The script loads with five markers that will not trigger because no conditions are associated with them. To activate markers, you will need to select and enter the set of conditions you require for each one. Alerts You can configure alerts on this script. They will trigger whenever one of the configured markers triggers. Alerts do not repaint, so they trigger at the bar's close—which is also when the markers will appear. █  HOW TO USE IT As a rule, I do not prescribe expected use of my indicators, as traders have proved to be much more creative than me in using them. Additionally, I tend to think that if you expect detailed recommendations from me to be able to use my indicators, it's a sign you are in a precarious situation and should go back to the drawing board and master the necessary basics that will allow you to explore and decide for yourself if my indicators can be useful to you, and how you will use them. I will make an exception for this thing, as it presents fairly novel information. I will use simple logic to surmise potential uses, as contrary to most of my other indicators, I have NOT used this one to actually trade. Markets have a way of throwing wrenches in our seemingly bullet-proof rationalizing, so drive cautiously and please forgive me if the pointers I share here don't pan out. The first thing to do is to disable your normal bars. You can do this by clicking on the eye icon that appears when you hover over the symbol's name in the upper-left corner of your chart. The absolute value and polarity of DV​ mean little without perspective; that's why I include both total volume​ for the bar and the percentage that DV​ represents of that total volume​. I interpret a low DV% value as indecision. If you share that opinion, you could, let's say, configure one of the markers on "DV% > 80%", for example (to do so you would enter "8" in the condition field of any marker, and "80" in the limit field for condition 8, below the marker conditions). I also like to analyze price action on the bar with DV%. Small DV% values should often produce small candle bodies. If a small DV% value occurs on a bar with much movement and high volume​, I'm thinking "tough battle with potential explosive power when one side wins". Conversely, large bodies with high DV% mean that large volume​ is breaching through multiple levels, or that nobody is suddenly willing to take the other side of a normal volume of trades. I find the POC lines really interesting. First, they tell us the price point where the most significant action (taking into account both price occurrences AND volume​) during the bar occurred. Second, they can be useful when compared against past values. Third, their color helps us in figuring out which ones are the most significant. Unsurprisingly, bunches of orange POCs tend to appear in consolidation zones, in pauses, and before reversals. It may be useful to often focus more on POC progression than on `close` values. This is not to say that OHLC values are not useful; looking, as is customary, for higher highs or lower lows, or for repeated tests of precise levels can of course still be useful. I do like how POCs add another dimension to chart readings. What should you do with the ticks delta above bars? Old-time ticker tape readers paid attention to the sounds coming from it (the "ticker" moniker actually comes from the sound they made). They knew activity was picking up when the frequency of the "ticks" increased. My thinking is that the total number of ticks will help you in the same way, since increasing updates usually mean growing interest—and thus perhaps price movement, as increasing volatility​ or volume​ would lead us to surmise. Ticks delta can help you figure out when proportionally large, random orders come in from traders with other perspectives than the short-term price action you are typically working with when you use this tool. Just as volume delta, ticks delta are one more informational component that can help you confirm convergence when building your opinions on price action. What are strong bars? They are an attempt to identify significance. They are like a default marker, except that instead of displaying "Mx▲/▼" below/above the bar, the candle's body is outlined in bright​ bull/bear color when one is detected. Strong bars require a respectable amount of conditions to be met (you can see and re-configure them in the inputs). Think of them as pushes rather than indications of an upcoming, strong and multi-bar move. Pushes do, for sure, often occur at the beginning of strong trends. You will often see a few strong bars occur at 2-3 bar intervals at the beginning or middle of trends. But they also tend to occur at tops/bottoms, which makes their interpretation problematic. Another pattern that you will see quite frequently is a final strong bar in the direction of the trend, followed a few bars later by another strong bar in the reverse direction. My summary analyses seemed to indicate these were perhaps good points where one could make a bet on an early, risky reversal entry. The last piece of information displayed by the indicator is the color of the candle bodies. Three possible colors are used. Bull/bear is determined by the polarity of DV​, but only when the bar's polarity matches that of DV​. When it doesn't, the color is the divergence color (orange, by default). Whichever color is used for the body, its intensity is determined by the DV% value. Maximum intensity occurs when DV%=100, so the more significant DV% values generate more noticeable colors. Body colors can be useful when looking to confirm the convergence of other components. The visual effect this creates hopefully makes it easier to detect patterns on the chart. One obvious methodology that comes to mind to trade with this tool would be to use another indicator like Technical Ratings at a higher timeframe to identify the larger context's trend, and then use this tool to identify entries for short-term trades in that direction. █  NOTES AND RAMBLINGS Instant Calculations This indicator uses instant values calculated on the bar only. No moving averages or calculations involving historical periods are used. The only exception to this rule is in some of the marker conditions like "Two consecutive DV+ values", where information from the previous bar is used. Trading Small vs Long Timeframes I never trade discretionary at the 5sec–5min timeframes this indicator was designed to be used with; I trade discretionary at 1D, 1W and 1M timeframes, and let systems trade at smaller timeframes. The higher the timeframe you trade at, the fewer fees you will pay because you trade less and are not churning trading volume​, as is inevitable at smaller timeframes. Trading at higher timeframes is also a good way to gain an instant edge on most of the trading crowd that has its nose to the ground and often tends to forget the big picture. It also makes for a much less demanding trading practice, where you have lots of time to research and build your long-term opinions on potential future outcomes. While the future is always uncertain, I believe trades riding on long-term trends have stronger underlying support from the reality outside markets. To traders who will ask why I publish an indicator designed for small timeframes, let me say that my main purpose here is to showcase what can be done with Pine. I often see comments by coders who are obviously not aware of what Pine is capable of in 2021. Since its humble beginnings seven years ago, Pine has grown and become a serious programming language. TradingView's growing popularity and its ongoing commitment to keep Pine accessible to newcomers to programming is gradually making Pine more and more of a standard in indicator and strategy programming. The technical barriers to entry for traders interested in owning their trading practice by developing their personal tools to trade have never been so low. I am also publishing this script because I value volume​ delta information, and I present here what I think is an original way of analyzing it. Performance The script puts a heavy load on the Pine runtime and the charting engine. After running the script for a while, you will often notice your chart becoming less responsive, and your chart tab can take longer to activate when you go back to it after using other tabs. That is the reason I encourage you to set the number of historical values displayed on bars to the minimum that meets your needs. When your chart becomes less responsive because the script has been running on it for many hours, refreshing the browser tab will restart everything and bring the chart's speed back up. You will then lose the information displayed on elapsed bars. Neutral Volume This script represents a departure from the way I have previously calculated volume​ delta in my scripts. I used the notion of "neutral volume" when inspecting intrabar timeframes, for bars where price did not move. No longer. While this had little impact​ when using intrabar inspection because the minimum usable timeframe was 1min (where bars with zero movement are relatively infrequent), a more precise way was required to handle realtime updates, where multiple consecutive prices often have the same value. This will usually happen whenever orders are unable to move across the bid/ask levels, either because of slow action or because a large-volume​ bid/ask level is taking time to breach. In either case, the proper way to calculate the polarity of volume​ delta for those updates is to use the last known polarity, which is how I calculate now. The Order Book Without access to the order book's levels (the depth of market), we are limited to analyzing transactions that come in the TradingView feed for the chart. That does not mean the volume​ delta information calculated this way is irrelevant; on the contrary, much of the information calculated here is not available in trading consoles supplied by exchanges/brokers. Yet it's important to realize that without access to the order book, you are forfeiting the valuable information that can be gleaned from it. The order book's levels are always in movement, of course, and some of the information they contain is mere posturing, i.e., attempts to influence the behavior of other players in the market by traders/systems who will often remove their orders when price comes near their order levels. Nonetheless, the order book is an essential tool for serious traders operating at intraday timeframes. It can be used to time entries/exits, to explain the causes of particular price movements, to determine optimal stop levels, to get to know the traders/systems you are betting against (they tend to exhibit behavioral patterns only recognizable through the order book), etc. This tool in no way makes the order book less useful; I encourage all intraday traders to become familiar with it and avoid trading without one.
Pine Script™ indicator
by LucF
101
Script Stopwatch - PineCoders FAQ█ WARNING The publication of our LibraryStopwatch has deprecated this publication. █ ORIGINAL DESCRIPTION This script calculates the run time of a Pine script. While its numbers are not very precise and it doesn’t work on all scripts, it will help developers calculate run times more precisely than by hand, and so provides Pine coders with an additional profiling tool to help them optimize their code. How to use the code • Place the code included between the up/down arrows after your script’s input() calls. • Comment out the display modes you don’t want to use. • Save your script, wait and look at the results. • Results show in different colors, depending on the average time per bar: - green for < 5 ms - dark red for < 50 ms - bright red for > 50 ms (the maximum allowed is 200). How the code works The code in this script starts by saving the value of the timenow variable on the first bar. While the time variable returns the time at the beginning of the bar, timenow returns the current time. The code then follows the progression of timenow during the script’s execution. The variable only updates every second, so in between updates the script makes an estimate of the total time elapsed by adding the last average time per bar calculated to each bar that passes until timenow increases by another 1000 because one more second has elapsed since its last update. At that point a new, current average time per bar is calculated and the cycle repeats. The code only calculates elapsed time for the initial run. Once the realtime bar is hit, timing stops so that time spent in the realtime bar does not affect the numbers once they have been calculated on the script’s initial pass over the dataset. Notes • If results show zero elapsed time, it’s most probably because your script executes in less than one second, which is very good. In that case timenow hasn’t changed, so no timing can be calculated. • The code is quirky and doesn’t work on all scripts. • It doesn’t properly time execution of security() calls. • The average time per bar will sometimes vary quite a bit with changes in chart resolution. Look first. Then leap.
Pine Script™ indicator
by PineCoders
9
Dual Dynamic Fibonacci Retracement — Long and Short Duration Title : "The Dual-Dynamic Fibonacci Retracement Script: An Advanced Tool for Comprehensive Market Analysis" As the author of the "Dual-Dynamic Fibonacci Retracement Script", I am delighted to introduce you to this cutting-edge tool for technical analysis. Unlike conventional Fibonacci scripts, this advanced model incorporates multiple unique features and adjustments that make it a powerful asset for any market analyst. Whether you're dealing with forex, commodities, equities or any other market, this script is versatile enough to enhance your trading strategy. Uniqueness & Differentiation: The "Dual-Dynamic Fibonacci Script" stands out by offering two distinct lookback periods. This feature is what separates it from other scripts available in the market. The first lookback period is longer, focusing on capturing broader market trends. The second lookback period is shorter, allowing for a more granular analysis of near-term market fluctuations. This dual perspective provides a more comprehensive view of the market, allowing you to see both the forest and the trees at the same time. Fibonacci Levels: While offering the standard Fibonacci retracement levels (0.236, 0.382, 0.5, 0.618, 0.786, and 1.0), the script also gives you the ability to plot 0.114 and 0.886 levels. These additional levels offer an extra layer of depth to your analysis, and can prove crucial in high-volatility markets where they often serve as significant support and resistance points. Customizable Line Shifts and Extends: This script provides options for customization of the shift and extension of the plotted lines. This means you can adjust the start and end points of the Fibonacci lines according to your personal trading style and strategy. This level of personalization is not typically available in other scripts, and it allows for a more tailored visual representation. Flexible Trading Positioning: Depending on whether the closing price is above or below the midpoint of the pivot high and pivot low, the Fibonacci retracement levels are adjusted accordingly. This ensures the script remains relevant and useful regardless of market conditions. Clean Visualization: To prevent clutter and maintain focus on the most relevant price action, the script removes old Fibonacci lines and plots new ones once a new pivot high or low is identified. This clean visualization helps keep your analysis focused and sharp. How to Use the Script: To get started, simply adjust the lookback periods according to your trading strategy. If you're a long-term investor or prefer swing trading, a longer lookback period might be appropriate. Conversely, if you're a day trader, a shorter lookback period might be more beneficial. The "Shift" and "Extend" inputs allow you to control the positioning of the Fibonacci lines on your chart. Positive values shift the lines to the right, while negative values shift them to the left. You also have the choice to plot the additional Fibonacci levels (0.114 and 0.886) via the "Plot 0.114 and 0.886 levels?" input. Similarly, the "Plot second set of levels?" input lets you decide whether to display the second set of Fibonacci levels derived from the shorter lookback period. Like any technical analysis tool, this script is most effective when used in conjunction with other indicators and methods of analysis. It is designed to work well in trending markets, where Fibonacci retracements can often indicate potential reversal levels. However, it's always recommended to use a holistic approach to market analysis to maximize the likelihood of successful trades. Note: the two lines drawn on the chart are there to help the user identify the levels from which the two respective Fib sequences are calculated. ~~~ Input Explanations: Long Period Pivot High/Low Lookback and Short Period Pivot High/Low Lookback : These settings determine the length of the lookback periods for the long-term and short-term pivot points, respectively. A pivot point is a technical analysis indicator used to determine the overall trend of the market over different time frames. The pivot points are then used to calculate the Fibonacci levels. A longer lookback period will identify pivot points over a broader time frame, capturing major market trends, while a shorter lookback period will identify pivot points over a narrower time frame, capturing more immediate market movements. Long Period Fibonacci Level Shift and Short Period Fibonacci Level Shift : These inputs control the shift of the Fibonacci levels based on the long and short lookback periods, respectively. If you want to shift the Fibonacci levels to the right, increase the value. If you want to shift the Fibonacci levels to the left, decrease the value. This allows you to adjust the Fibonacci levels to better align with your analysis. Long Period Fibonacci Level Extend and Short Period Fibonacci Level Extend : These inputs control the extension of the Fibonacci levels based on the long and short lookback periods, respectively. If you want the Fibonacci levels to extend further to the right, increase the value. If you want the Fibonacci levels to extend less to the right, decrease the value. This feature provides the flexibility to adjust the length of the Fibonacci levels according to your personal trading preferences and strategy. Plot 0.114 and 0.886 levels? : This setting gives you the ability to plot the additional 0.114 and 0.886 Fibonacci levels. These levels provide extra depth to your analysis, particularly in highly volatile markets where they can act as significant support and resistance levels. Plot second set of levels? : This input allows you to decide whether to plot the second set of Fibonacci levels based on the short lookback period. Displaying this second set of levels can provide a more granular view of market movements and potential reversal points, enhancing your overall analysis.
Pine Script™ indicator
by StockJustice
2
Volatility Adaptive Signal Tracker (VAST)The Adaptive Trend Following Buy/Sell Signals Pine Script is designed to help traders identify and capitalize on market trends using an adaptive trend-following strategy. This script focuses on generating reliable buy and sell signals by analyzing market trends and volatility. It simplifies the trading process by providing clear signals without plotting additional lines, making it easy to use and interpret. Key Features: Adaptive Trend Following: The script employs an adaptive trend-following approach that leverages market volatility to generate buy and sell signals. This method is effective in both trending and volatile markets. Inputs and Customization: The script includes customizable parameters for the Simple Moving Average (SMA) length, the Average True Range (ATR) length, and the ATR multiplier. These inputs allow traders to adjust the sensitivity of the signals to match their trading style and market conditions. Signal Generation: Buy Signal: Generated when the closing price crosses above the upper adaptive band, indicating a potential upward trend. Sell Signal: Generated when the closing price crosses below the lower adaptive band, indicating a potential downward trend. Visual Signals: The script uses plotshape to mark buy signals with green labels below the bars and sell signals with red labels above the bars. This clear visual representation helps traders quickly identify trading opportunities. Alert Conditions: The script sets up alert conditions for both buy and sell signals. Traders can use these alerts to receive notifications when a signal is generated, ensuring they do not miss any trading opportunities. How It Works: SMA Calculation: The script calculates the Simple Moving Average (SMA) over a specified period, which helps in identifying the general trend direction. ATR Calculation: The Average True Range (ATR) is calculated to measure market volatility. Adaptive Bands: Upper and lower adaptive bands are created by adding and subtracting a multiple of the ATR to the SMA, respectively. Signal Logic: Buy signals are generated when the closing price crosses above the upper band, while sell signals are generated when the closing price crosses below the lower band. Example Use Case: A trader looking to capitalize on medium-term trends in the Nifty futures market can use this script to receive timely buy and sell signals. By customizing the SMA length and ATR parameters, the trader can fine-tune the script to match their trading strategy, ensuring they enter and exit trades at optimal points. Benefits: Simplicity: The script provides clear buy and sell signals without cluttering the chart with additional lines or indicators. Adaptability: Customizable parameters allow traders to adapt the script to various market conditions and trading styles. Alerts: Built-in alert conditions ensure traders receive timely notifications, helping them to act quickly on trading signals. How to Use: Open TradingView: Go to the TradingView website and log in. Create a New Chart: Click on the “Chart” button to open a new chart. Open the Pine Script Editor: Click on the “Pine Editor” tab at the bottom of the chart. Create a New Script: Delete any default code in the Pine Script editor and paste the provided script. Add to Chart: Click on the “Add to Chart” button to compile and add the script to your chart. Save the Script: Click “Save” and name the script. Set Alerts: Right-click on the chart, select “Add Alert,” and choose the appropriate condition to set alerts for buy and sell signals.
Pine Script™ indicator
by Shreeyash_Chiddarwar
Point and Figure Chart - LiveHello Traders, This is "Point and Figure Chart (PnF)" script that run in separated window in real time. The separated PnF chart window is timeless, so no relation with the time on the chart. PnF chart consist of "X" and "O" columns. While "X" columns represents rising prices, "O" column represents a falling price. If you have no idea about what PnF charting is then you should search for "Point and Figure Charting" on the net and get some info before using this script. Now lets talk about details. PnF Chart requires at least two variables to be set => Box size and Reversal. Box size represents the size of each X/O in PnF chart and the reversal is used to calculate new X/O or reversal. for example if currrent column is X column then for new "X", "box size * 1" move is needed and for new "O" column or reversal, "box size * revelsal" move is needed. in the script I use lines as X/O columns. In the options you can set "Box Size Assingment Method". you have 3 options Traditional, ATR, Percentage . what are they? Traditional: user-defined box size, means you can set the box size as you wish, using the option . if you use this option then you should set it accordingly. ATR : that's dynamic box size scaling and on each columns it's calculated once, you can set length for ATR Percentage: that's also dynamic box size scaling according to closing price when new column appeared. if you use this option then you should set it accordingly. Reversal: The reversal is typically 3 but you can change it as you wish "Change Bar Color by PnF Trend": if you enable this option then bar color changes by PnF columns, by default it's not enabled "Change Column Color When Breakout Occurs": PnF color changes if Double Top/Bottom breakout accours. enabled by default and you can set the colors as you wish using the options "Change Bar Color When Breakout Occurs": bar colors changed if Double Top/Bottom breakout accours. enabled by default and you can set the colors as you wish using the options the script checks only Double Top/Bottom breakouts at the moment. there are many other breakouts such Triple/Quadruple, Ascending/Descending Triple Top/Bottom breakouts, Catapult etc. Also the script shows new X/O level and reversal Levels in PnF window. An example: If you enable "Change Bar Color by PnF Trend" option: An example if you disable the option "Change Column Color When Breakout Occurs You may want to see my another/older "Point and Point Chart" script as well. you can find it in my profile/published scripts and in the Public Library. I use same PnF calculation algorithm in both scripts. Enjoy!
Pine Script™ indicator
by LonesomeTheBlue
28
Psychological levels (Bank levels) PsychoLevels v2 - TartigradiaPsychological levels (Bank levels) plots "round" price levels above and below current price, by truncating after the nth leftmost digits, based on neuroscience research of how humans intuitively calculate in logarithms. Psychological levels, also called bank levels, are "round" price numbers around which price often experience resistance or support, because traders and investors tend to set orders around these round numbers. Calculation here is fully automatic and dynamic, contrary to other similar scripts, this one uses a mathematical calculation that extracts the 1, 2 or 3 leftmost digits and calculate the previous and next level by incrementing/decrementing these digits. This means it works for any symbol under any price range. This approach is based on neuroscience research, which found that human brains intuitively approximate numbers on a logarithmic scale, adults and children alike, and similarly to macaques, for more info see Numerical Cognition , Weber-Fechner Law , Zipf law. For example, if price is at 0.0421, the next major price level is 0.05 and medium one is 0.043. For another asset currently priced at 19354, the next and previous major price levels are 20000 and 10000 respectively, and the next/previous medium levels are 20000 and 19000, and the next/previous weak levels are 19400 and 19300. Usage: * By default, strong upper level is in green, strong lower level is in red, medium upper level is in blue, medium lower level is in yellow, and weak levels aren't displayed but can be. Half levels are also displayed, in a darker color. Strong levels are increments of the first leftmost digit (eg, 10000 to 20000), medium levels are increments of the second leftmost digit (eg, 19000 to 20000), and weak levels of the third leftmost digit (eg, 19100 to 19200). Instead of plotting all the psychological levels all at once as a grid, which makes the chart unintelligible, here the levels adapt dynamically around the current price, so that they show the upper/lower levels relatively to the current price. * A simple moving average is implemented, so that "half-levels" are also displayed when relevant (eg, medium level can also display 19500 instead of only 19000 or 20000). This can be disabled by setting smoothing to 1. * By default, the script runs on the daily timeframe, whatever the current chart's timeframe is. This is to reduce the variability in levels, to make it less noisy than intraday price movement, but this can be changed in the settings. * The step can be adjusted to increase the gap between levels, eg, if you want to display one every 2 levels then input step = 2 (eg, 22000, 24000, 26000, etc), or if you want to display quarter levels, input 0.25 (eg, 22000, 22250, 22500, etc). The default values should fit most use cases and cover most psychological levels. I made this script mainly to train with PineScript, but I found it surprisingly accurate to define levels that are respected by price movements. So I guess it can be useful for new traders and experienced traders alike, as it's easy to forget that psychological levels can often be as strong if not stronger than technical levels. It can also be used to quickly screen other minor assets for trading opportunities. For example, a hybrid strategy would be to manually define levels on BTCUSD but using this script to automatically define levels in crypto altcoins and quickly screen them for a trade opportunity that can be greater than with BTCUSD but with the same trend. Changes compared to v1: * Deduplicated redundant calculations and hence faster script. * Added half-step levels, which allows to more easily see breakouts (because the levels are still on-screen). * All steps are now configuration on the GUI. * Revamped color scheme. * And major reasons to post as a separate v2 script rather than updating: because we can't update the original description nor screenshot. I have now read more about the House Rules and saw other scriptmakers, so I am trying to write better descriptions like wizards do, by explaining not only how the script works but what the underlying financial concept is to a neophyte audience.
Pine Script™ indicator
by tartigradia
3
Vertical LinesThis script plots vertical lines on charts or indicators. Unfortunately pinescript is lacking a vertical line plotting function. Vertical lines are useful to mark events, such as crossover of levels, indicators signals or as a time marker. After searching the internet for a long time and trying different scripts, this script is the simplest and visually the best. You would think that plotting a vertical line would be relatively easy, it is not! I thank the unknow author for sharing this solution and now I will share it on tradingview to make it readily available to anybody that needs it. RSI crossover signals are used as an example in this script. When the RSI crosses over 70 or below 30, the script plots a red or green vertical line. The script plots a vertical line as a histogram bar. The histogram bar must have a height. Setting the height near infinity like 1e20 will cover all the ranges from top to bottom in most charts, but doesn't work all the time. If the chart range is small in values, the line is not plotted or the chart is visually compressed because the top of the bar is also a data point in the chart. Another solution is to find the highest point in the chart and multiply it by a number from 2 to 10 to set the top of the histogram bar. But this solution doesn't work if the line is drawn in the indicator window. additionally if the chart or indicator includes negative values, a histogram bar with a negative height must be concatenated to the histogram bar with a positive height to cover the positive and negative range. It would seem intuitive to include a vertical plot function since it is very useful and pinescript already has a horizontal line plot function called Hline. But pinescript is becoming less intuitive, and redundant. A case in point is Version 4 variable declaration and naming, it less intuitive and more redundant than previous versions. I beg Tradingview to adopt a more refined scripting language such as Matlab or Python for charting purposes. These languages can be easily ported to other analysis programs for AI or statistical analysis.
Pine Script™ indicator
by nagihatoum
4
Adapting a built-in [PineCoders]█  OVERVIEW This Pine script shows how it can be quite simple to personalize a built-in indicator for your needs. █  OUR SCRIPT Our objective was to add the current values for volume​ and its moving average in prominent view, and use brighter colors than the built-in. We started with the source code from the "Volume" built-in indicator. You can access the source code of many built-ins from the Pine Editor by clicking the "Open" button and choosing "New default built-in script..." We changed the variable names so they conform to our Coding Conventions . Everybody is of course free to code their scripts the way they want; the conventions provide guidelines for those interested in Pine-specific recommendations. We use our conventions to make our code more readable, which helps readers of open-source publications. As Uncle Bob, a.k.a. Robert Cecil Martin, argues in his "Clean Code" book, code that is easier to read is also useful for its first user: you. We assigned the colors we use to constants because they are used in multiple places in the script. If we decide to change them, we only need to change the constant definitions for the change to trickle down to the rest of the code. We used the `inline` and `tooltip` parameters of input() to better organize our inputs and provide extra information under an "i" icon when needed. We wanted to pack more information in the display of the moving average and volume​ than just the values, so we color-coded their background:  • When the MA is rising, the background of its table cell is in the bull color, otherwise it's in the bear color. The period used for the MA is also displayed in that cell's legend.  • When the current volume's value is higher/lower than its MA, the background of its cell is of bull/bear color. We use a Pine table to display our values. We use extra cells to provide a configurable margin to the left, and a small space between the two values. Because we only use constant colors in this script (i.e., values that are known at compile time), users can change the colors in the "Setting/Style" tab's color widgets. Users of the script can also use the tab to change other attributes of the plots. Look first. Then leap.
Pine Script™ indicator
by PineCoders
21
Curious Buy - Sell Indicator - Institutional Zones (Smart Money)How the Script Works: 1. The Scripts identifies Institutional Demand , Supply & Neutral Zones with FIBS on the scripts with Rectangle BOX with labels in advance. User can insert desired start and end value to plot institutional zones 2. Script generates BUY - SELL signals shape based on candle stick formation in live market and labels with BUY - SELL image for easy identification 3. Script gives pop message EXIT SHORT once Buy spotted and candle close above the buy signal and same way EXIT LONG once Sell spotted and candle close below the buy signal 4. Scripts identifies the candle closing above the BUY - SELL signals Eg - If buy spotted the candle closing above the BUY signal with display with BLUE color Candle same way for sell signal the candle closing below the sell signal candle with display with BLACK color candle. 5. Script spots fake signals which are not valid and can be ignored by the end user 6. Three EMA's 20,50,200 has implemented to identify the strength of the market 7. Scripts identifies OPEN = LOW & OPEN = HIGH candle stick to spot the Institutional BUY - SELL activity 8. The script provides visual clues on the chart to help users identify potential trading opportunities. 9. The script provides visual clues on the chart to help users identity potential trading opportunities in live market 10. The looks and parameters of the script can be modified by end user to customize and adapt to different strategy. 11. With the script user can check higher time frame DAILY \ WEEKLY BUY - SELL signals to plan intraday trades and plan safe BUY - SELL positions. How Users Can Make Profit Using This Script: 1. Identify potential BUY - LONG opportunities: When a valid BUY is detected and condition is met, it is suggested to opening BUY position with stoploss below the BUY signal spotted candle. Safe users can execute BUY position once BLUE COLOR candle is formed, Wait for pull back to reduce the stoploss 2. Identify potential SELL - SHORT opportunities: When a valid SELL is detected and condition is met, it suggests a potential opening SELL positions with stoploss above the BUY signal spotted candle. Safe users can execute SELL position once BLACK COLOR candle is formed, Wait for pull back to reduce the stoploss. 3. Script generated BUY - SELL signal met target with the Institutional zone. Eg if BUY spotted at demand zone target will be neutral zone & Supply zone. 4. Script designed for user to spot high probability trades when BUY SIGNAL SPOTTED at the Institutional Demand zone same way SELL SIGNAL SPOTTED AT INSTITUTIONAL supply zone. 5. Combine with additional analysis: Users can utilize this script as a tool in their overall trading strategy. They can combine the signals with fundament analysis , market sentiment to make more informed trading decision 6.Set risk management measures: It is important for users to implement proper risk management strategies when trading based on the scripts signals. To avoid potential losses user once spotted BUY - SELL execute the long or short position. Ensure to place the stoploss to avoid potential losses and place the target. Once your trade is moving in your favor can trial your stoploss to cost and protect the profits.
Pine Script™ indicator
by curioustraderr
12
[blackcat] L2 Zero-lag EMA Swing TradeLevel: 2 Background This script is a comprehensive work of mine, incorporating Ehlers zero-lag EMA and my first script published: MA fingerprint for long entries. Function Ehlers zero-lag EMA algorithm in this scripts is mainly used for short signal production, while my MA fingerprint algorithm is used for long entries. Key Signal a ---> Ehlers Zero-lag EMA fast line for subjective long jugement b ---> Ehlers Zero-lag EMA slow line for subjective short jugement long --> Swing long entry with partial postion short --> Swing short entry with partial postion Remarks Feedbacks are appreciated. This script is optimized for 1D time frame. Readme In real life, I am a prolific inventor. I have successfully applied for more than 60 international and regional patents in the past 12 years. But in the past two years or so, I have tried to transfer my creativity to the development of trading strategies. Tradingview is the ideal platform for me. I am selecting and contributing some of the hundreds of scripts to publish in Tradingview community. Welcome everyone to interact with me to discuss these interesting pine scripts. The scripts posted are categorized into 5 levels according to my efforts or manhours put into these works. Level 1 : interesting script snippets or distinctive improvement from classic indicators or strategy. Level 1 scripts can usually appear in more complex indicators as a function module or element. Level 2 : composite indicator/strategy. By selecting or combining several independent or dependent functions or sub indicators in proper way, the composite script exhibits a resonance phenomenon which can filter out noise or fake trading signal to enhance trading confidence level. Level 3 : comprehensive indicator/strategy. They are simple trading systems based on my strategies. They are commonly containing several or all of entry signal, close signal, stop loss, take profit, re-entry, risk management, and position sizing techniques. Even some interesting fundamental and mass psychological aspects are incorporated. Level 4 : script snippets or functions that do not disclose source code. Interesting element that can reveal market laws and work as raw material for indicators and strategies. If you find Level 1~2 scripts are helpful, Level 4 is a private version that took me far more efforts to develop. Level 5 : indicator/strategy that do not disclose source code. private version of Level 3 script with my accumulated script processing skills or a large number of custom functions. I had a private function library built in past two years. Level 5 scripts use many of them to achieve private trading strategy.
Pine Script™ indicator
by blackcat1402
6
Higher-timeframe requests█   OVERVIEW This publication focuses on enhancing awareness of the best practices for accessing higher-timeframe (HTF) data via the request.security() function. Some "traditional" approaches, such as what we explored in our previous `security()` revisited publication, have shown limitations in their ability to retrieve non-repainting HTF data. The fundamental technique outlined in this script is currently the most effective in preventing repainting when requesting data from a higher timeframe. For detailed information about why it works, see this section in the Pine Script™ User Manual . █   CONCEPTS Understanding repainting Repainting is a behavior that occurs when a script's calculations or outputs behave differently after restarting it. There are several types of repainting behavior, not all of which are inherently useless or misleading. The most prevalent form of repainting occurs when a script's calculations or outputs exhibit different behaviors on historical and realtime bars. When a script calculates across historical data, it only needs to execute once per bar, as those values are confirmed and not subject to change. After each historical execution, the script commits the states of its calculations for later access. On a realtime, unconfirmed bar, values are fluid . They are subject to change on each new tick from the data provider until the bar closes. A script's code can execute on each tick in a realtime bar, meaning its calculations and outputs are subject to realtime fluctuations, just like the underlying data it uses. Each time a script executes on an unconfirmed bar, it first reverts applicable values to their last committed states, a process referred to as rollback . It only commits the new values from a realtime bar after the bar closes. See the User Manual's Execution model page to learn more. In essence, a script can repaint when it calculates on realtime bars due to fluctuations before a bar's confirmation, which it cannot reproduce on historical data. A common strategy to avoid repainting when necessary involves forcing only confirmed values on realtime bars, which remain unchanged until each bar's conclusion. Repainting in higher-timeframe (HTF) requests When working with a script that retrieves data from higher timeframes with request.security() , it's crucial to understand the differences in how such requests behave on historical and realtime bars . The request.security() function executes all code required by its `expression` argument using data from the specified context (symbol, timeframe, or modifiers) rather than on the chart's data. As when executing code in the chart's context, request.security() only returns new historical values when a bar closes in the requested context. However, the values it returns on realtime HTF bars can also update before confirmation, akin to the rollback and recalculation process that scripts perform in the chart's context on the open bar. Similar to how scripts operate in the chart's context, request.security() only confirms new values after a realtime bar closes in its specified context. Once a script's execution cycle restarts, what were previously realtime bars become historical bars, meaning the request.security() call will only return confirmed values from the HTF on those bars. Therefore, if the requested data fluctuates across an open HTF bar, the script will repaint those values after it restarts. This behavior is not a bug; it's simply the default behavior of request.security() . In some cases, having the latest information from an unconfirmed HTF bar is precisely what a script needs. However, in many other cases, traders will require confirmed, stable values that do not fluctuate across an open HTF bar. Below, we explain the most reliable approach to achieve such a result. Achieving consistent timing on all bars One can retrieve non-fluctuating values with consistent timing across historical and realtime feeds by exclusively using request.security() to fetch the data from confirmed HTF bars. The best way to achieve this result is offsetting the `expression` argument by at least one bar (e.g., `close [1 ]`) and using barmerge.lookahead_on as the `lookahead` argument. We discourage the use of barmerge.lookahead_on alone since it prompts the function to look toward future values of HTF bars across historical data, which is heavily misleading. However, when paired with a requested `expression` that includes a one-bar historical offset, the "future" data the function retrieves is not from the future. Instead, it represents the last confirmed bar's values at the start of each HTF bar, thus preventing the results on realtime bars from fluctuating before confirmation from the timeframe. For example, this line of code uses a request.security() call with barmerge.lookahead_on to request the close price from the "1D" timeframe, offset by one bar with the history-referencing operator [ ] . This line will return the daily price with consistent timing across all bars: float htfClose = request.security(syminfo.tickerid, "1D", close , lookahead = barmerge.lookahead_on) Note that:  • This technique only works as intended for higher-timeframe requests .  • When designing a script to work specifically with HTFs, we recommend including conditions to prevent request.security() from accessing timeframes equal to or lower than the chart's timeframe, especially if you intend to publish it. In this script, we included an if structure that raises a runtime error when the requested timeframe is too small.  • A necessary trade-off with this approach is that the script must wait for an HTF bar's confirmation to retrieve new data on realtime bars, thus delaying its availability until the open of the subsequent HTF bar. The time elapsed during such a delay varies with each market, but it's typically relatively small. 👉 Failing to offset the function's `expression` argument while using barmerge.lookahead_on will produce historical results with lookahead bias , as it will look to the future states of historical HTF bars, retrieving values before the times at which they're available in the feed. See the `lookahead` and Future leak with `request.security()` sections in the Pine Script™ User Manual for more information. Evolving practices The fundamental technique outlined in this publication is currently the only reliable approach to requesting non-repainting HTF data with request.security() . It is the superior approach because it avoids the pitfalls of other methods, such as the one introduced in the `security()` revisited publication. That publication proposed using a custom `f_security()` function, which applied offsets to the `expression` and the requested result based on historical and realtime bar states. At that time, we explored techniques that didn't carry the risk of lookahead bias if misused (i.e., removing the historical offset on the `expression` while using lookahead), as requests that look ahead to the future on historical bars exhibit dangerously misleading behavior. Despite these efforts, we've unfortunately found that the bar state method employed by `f_security()` can produce inaccurate results with inconsistent timing in some scenarios, undermining its credibility as a universal non-repainting technique. As such, we've deprecated that approach, and the Pine Script™ User Manual no longer recommends it. █   METHOD VARIANTS In this script, all non-repainting requests employ the same underlying technique to avoid repainting. However, we've applied variants to cater to specific use cases, as outlined below: Variant 1 Variant 1, which the script displays using a lime plot, demonstrates a non-repainting HTF request in its simplest form, aligning with the concept explained in the "Achieving consistent timing" section above. It uses barmerge.lookahead_on and offsets the `expression` argument in request.security() by one bar to retrieve the value from the last confirmed HTF bar. For detailed information about why this works, see the Avoiding Repainting section of the User Manual's Other timeframes and data page. Variant 2 Variant 2 ( fuchsia ) introduces a custom function, `htfSecurity()`, which wraps the request.security() function to facilitate convenient repainting control. By specifying a value for its `repaint` parameter, users can determine whether to allow repainting HTF data. When the `repaint` value is `false`, the function applies lookahead and a one-bar offset to request the last confirmed value from the specified `timeframe`. When the value is `true`, the function requests the `expression` using the default behavior of request.security() , meaning the results can fluctuate across chart bars within realtime HTF bars and repaint when the script restarts. Note that:  • This function exclusively handles HTF requests. If the requested timeframe is not higher than the chart's, it will raise a runtime error .  • We prefer this approach since it provides optional repainting control. Sometimes, a script's calculations need to respond immediately to realtime HTF changes, which `repaint = true` allows. In other cases, such as when issuing alerts, triggering strategy commands, and more, one will typically need stable values that do not repaint, in which case `repaint = false` will produce the desired behavior. Variant 3 Variant 3 ( white ) builds upon the same fundamental non-repainting approach used by the first two. The difference in this variant is that it applies repainting control to tuples , which one cannot pass as the `expression` argument in our `htfSecurity()` function. Tuples are handy for consolidating `request.*()` calls when a script requires several values from the same context, as one can request a single tuple from the context rather than executing multiple separate request.security() calls. This variant applies the internal logic of our `htfSecurity()` function in the script's global scope to request a tuple containing open and `srcInput` values from a higher timeframe with repainting control. Historically, Pine Script™ did not allow the history-referencing operator [ ] when requesting tuples unless the tuple came from a function call, which limited this technique. However, updates to Pine over time have lifted this restriction, allowing us to pass tuples with historical offsets directly as the `expression` in request.security() . By offsetting all items in a tuple `expression` by one bar and using barmerge.lookahead_on , we effectively retrieve a tuple of stable, non-repainting HTF values. Since we cannot encapsulate this method within the `htfSecurity()` function and must execute the calculations in the global scope, the script's "Repainting" input directly controls the global `offset` and `lookahead` values to ensure it behaves as intended. Variant 4 (Control) Variant 4, which the script displays as a translucent orange plot, uses a default request.security() call, providing a reference point to compare the difference between a repainting request and the non-repainting variants outlined above. Whenever the script restarts its execution cycle, realtime bars become historical bars, and the request.security() call here will repaint the results on those bars. █   Inputs Repainting The "Repainting" input (`repaintInput` variable) controls whether Variant 2 and Variant 3 are allowed to use fluctuating values from an unconfirmed HTF bar. If its value is `false` (default), these requests will only retrieve stable values from the last confirmed HTF bar. Source The "Source" input (`srcInput` variable) determines the series the script will use in the `expression` for all HTF data requests. Its default value is close . HTF Selection This script features two ways to specify the higher timeframe for all its data requests, which users can control with the "HTF Selection" input (`tfTypeInput` variable):  1) If its value is "Fixed TF", the script uses the timeframe value specified by the "Fixed Higher Timeframe" input (`fixedTfInput` variable). The script will raise a runtime error if the selected timeframe is not larger than the chart's.  2) If the input's value is "Multiple of chart TF", the script multiplies the value of the "Timeframe Multiple" input (`tfMultInput` variable) by the chart's timeframe.in_seconds() value, then converts the result to a valid timeframe string via timeframe.from_seconds() . Timeframe Display This script features the option to display an "information box", i.e., a single-cell table that shows the higher timeframe the script is currently using. Users can toggle the display and determine the table's size, location, and color scheme via the inputs in the "Timeframe Display" group. █   Outputs This script produces the following outputs:  • It plots the results from all four of the above variants for visual comparison.  • It highlights the chart's background gray whenever a new bar starts on the higher timeframe, signifying when confirmations occur in the requested context.  • To demarcate which bars the script considers historical or realtime bars, it plots squares with contrasting colors corresponding to bar states at the bottom of the chart pane.  • It displays the higher timeframe string in a single-cell table with a user-specified size, location, and color scheme. Look first. Then leap.
Pine Script™ indicator
by PineCoders
14
40+ Coin Screener (workaround to 40 Security Limit Per Script) This is a far inferior method for a screener/scanner (compared to my first publication) but after looking at that script from a noobs eyes again, I could see how this form would be a lot easier to take in/understand so wanted to publish it. Everything that I could think of to mention about this is in my 1st pub so ill leave it to you to check it out...though I did include some comments in the script. It is pretty straight forward but if you have any questions don't hold them in. I'll answer them if I can. The only thing that is not in this one is setting up the alert feature so that you only have to create 1 alert per iteration of the script and it takes care of all of the coins for that iteration/set that is chosen in the settings (so please see previous script if would like to do this for your screener/scanner). To be PERFECTLY CLEAR, the workaround is to the issue of not being able to scan but only 40 coins per script. You can scan more than 40 per script but only if you create "batches" or "sets" that the user can select within the settings which set to use for each iteration of the script on the chart. That being, you have to the script multiple times to the chart and merge them into 1 window and merge the scales (instructions in first publications). Here in this script I am scanning 72 different coins that are the Margin Coins on KUCOIN. I have split them up into 3 sets (24 coins per set). I could have made 2 sets but the script will be slower to load and to respond (like, when it comes to receiving alerts), thus I split them up the way I did. If you want to change any of this there are slightly more details in the previous script. One great use-case that I LOVE about this particular version (and the way I use it) is right at the end of when I see a whole market dump/pump coming to an end and want to know which horse to bet on. Used to think whichever coin come out the fastest from the dump was the one to bet on but quickly learned that 1-2 (or even a few) hrs needs to go by first bc the ones that look the strongest in the beginning are NOT the ones to have performed the best when viewing the results 12 hrs later. IN FACT, many instances of using this exact script for reasons as such has taught me that the manipulators (I believe this to be the case as least) WANT everyone to bet on these that come out the gate the hardest and thus they make them move REALLY hard in the beginning then they QUICKLY become stagnant (moreso, they become WORSE than stagnant, they actually quickly retrace to put you into the negative so that you get out to get into the others now moving (to provide the market with more liquidity. They WANT you to get into a coin thats moving crazy hard so that they can then cease that movement once many fall for the trick just to then make that once strong looking coin now stagnant and make others move crazy hard. They wait for you to get out of the 1st and into the next set of movers just to do this time and time again bc hey, what are we sheep good for other than to provide the big guns with liquidity, am I right? Thats rhetorical, which you would know if you've ever had this happen to you (without a doubt MANY of you have). Let this script (above all other things) provide good evidence to back up this cynical way of viewing the markets to anyone that is questioning it. This prolonged time between when the dump is over and when the ACTUAL movers REALLY start moving can actually be of great benefit to us sheep if used correctly, Firstly, it gives us some time to determine if when we thought was the bottom, ACTUALLY was the bottom. That bottom is easily determined if there are no (or very few) coins that went any lower than the point in time that the script began calculating on. Secondly, it allows us time to wait for the REAL movers and shakers to start moving and shaking. One new feature that I LOVE that TV has implemented is the ability (once the script is added to the chart) to be able to click a point in time on the chart where you want the script to begin its calculations. If this point needs to be changed at any point in time then you can either go into the setting and input the time you wish or simply remove the script and add it again so that you are prompted to select another point in time. Ok, I think that everything I wanted to say. The next version that I will add will be probably my favorite and most used by yours truly...not to mention unique in a way that I have yet to see an implementation anything like it in all of TV's public library. Not to say its not there, but I have yet to come across it and I have DEFINITELY done my fair share of searching for it when I couldn't figure out how to code it for the longest time (though, I was and still am a noob so might get some great feedback on better ways to approach it, but we'll save that jabbering for the next of the publications. I hope each and every one of ya'll (yes, Im from the South) have the GREATEST of Thanksgivings (if in the US that is...I graced my parents with the best gift anyone could have given them 35 years ago on Thanksgiving....MEEEE ;) So I will sure as hell be having a great holiday. Thanks for checking out my script...you can "like" and leave a comment if you so feel the urge to...or not. Im not doing this for me, but rather to stretch my arms out as far as possible to benefit the most people as possible and more people would see the script if it has more likes/comments/traffic pointing towards it...not to mention as other publishers have...it IS gratifying to see a few likes in my side window, which btw, I have MANY more variations and completely diff types of scanners/screeners Ill be publishing in the future and to know that they've become of use....I"VE become of use to the community is very....pleasing to me and does (as I've also seen many publishers mention as well) drive me to want to publish ones that I originally thought I would keep for myself. Peace out people.
Pine Script™ indicator
by A_Traders_Edge
38
[blackcat] L1 Ehlers Phasor IndicatorLevel: 1 Background This script was requested by @pips_v1. "A cycle is one market characteristic that can be scientifically measured. Although they can be measured, they are still maddening because they are in essence ephemeral; they come and they go. Our recent research, however, indicates there is a fundamental cycle parameter that leads us to the correct trading strategy for any current market mode." by John Ehlers Function John Ehlers describe the principle of phasor indicator as "One easy way to picture a cycle is as an indicator arrow bolted to a rotating shaft, as can be seen in a phasor diagram. Each time the arrowhead sweeps through one complete rotation, a cycle is completed. The phase increases uniformly throughout the cycle. The phase continues for the next cycle but is usually drawn as reset to zero to start the next cycle." The parameter we use is the phase of the cycle. The measured phase tells us with great sensitivity when we are in the trend mode, enabling the capture of a large fraction of the trend movement. Key Signal Phase --> Ehlers Phasor signal Pros and Cons 100% John F. Ehlers definition translation of his publications, even variable names are the same. This help readers who would like to use pine to read his book. Remarks The 102th script for Blackcat1402 John F. Ehlers Week publication. Readme In real life, I am a prolific inventor. I have successfully applied for more than 60 international and regional patents in the past 12 years. But in the past two years or so, I have tried to transfer my creativity to the development of trading strategies. Tradingview is the ideal platform for me. I am selecting and contributing some of the hundreds of scripts to publish in Tradingview community. Welcome everyone to interact with me to discuss these interesting pine scripts. The scripts posted are categorized into 5 levels according to my efforts or manhours put into these works. Level 1 : interesting script snippets or distinctive improvement from classic indicators or strategy. Level 1 scripts can usually appear in more complex indicators as a function module or element. Level 2 : composite indicator/strategy. By selecting or combining several independent or dependent functions or sub indicators in proper way, the composite script exhibits a resonance phenomenon which can filter out noise or fake trading signal to enhance trading confidence level. Level 3 : comprehensive indicator/strategy. They are simple trading systems based on my strategies. They are commonly containing several or all of entry signal, close signal, stop loss, take profit, re-entry, risk management, and position sizing techniques. Even some interesting fundamental and mass psychological aspects are incorporated. Level 4 : script snippets or functions that do not disclose source code. Interesting element that can reveal market laws and work as raw material for indicators and strategies. If you find Level 1~2 scripts are helpful, Level 4 is a private version that took me far more efforts to develop. Level 5 : indicator/strategy that do not disclose source code. private version of Level 3 script with my accumulated script processing skills or a large number of custom functions. I had a private function library built in past two years. Level 5 scripts use many of them to achieve private trading strategy.
Pine Script™ indicator
by blackcat1402
12
Pinescript - Common String Functions Library by RRBCommon String Functions Library by RagingRocketBull 2021 Version 1.0 Pinescript now has strong support for arrays with many powerful functions, but still lacks built-in string functions. Luckily you can easily process and manipulate strings using arrays. This script provides a library of common string functions for everyday use, such as: indexOf, substr, replace, ascii_code, str_to_int etc. There are 100+ unique functions (130 including all implementations) It should serve as building blocks to speed up the development of your custom scripts. You should also be able to learn how Pinescript arrays works and how you can process strings. Similar libraries for Array and Statistical Functions are in the works. You can find the full list of functions below. Features: - 100+ unique string functions (130 including all implementations) in categories: lookup, testing, conversion, modification, extraction, type conversion, date and time, console output - Live Output for all/selected functions based on User Input. Test any function before using in script. - Live Unit Test Output for several functions based on pre-defined inputs. - Output filters: show unique functions/all implementations, grouping - Console customization options: set custom text size, color, page length - Support for Pages - auto splits output into pages with fixed length, use pages in your scripts - Several easy to use console output functions to speed up debugging/output. WARNING: - Compilation Time: 1 min Notes: - uses Pinescript v3 Compatibility Framework - this script is packed to the max and sets a new record in testing of Pinescript's limits: 500 local scopes, 4000+ lines, 180kb+ source size. It's not possible to add more ifs/fors/functions without reducing functionality - to fit the max limit of local scopes = 500 all ifs were replaced with ?: where possible, the number of function calls was reduced, some calls replaced with inline function code - ifs are faster (especially when lots of them are used in a for cycle), more readable, but ifs/fors/functions increase local scopes (+1) and compiled file size, have max nesting limit = 10. - ?: are slower (especially in for cycles), hard to read when nested, don't affect local scopes, reduce compiled file size, can't contain plots, for statements (break/continue) and sets of statements - for most array functions to work (except push), an array must be defined with at least 1 pre-existing dummy element 0. - if you see "String too long" error - enable Show Pages, reduce Max Chars Per Page < Max String Length limit = 4096. - if you see "Loop too long" error - hide/unhide or reattach the script - some functions have several implementations that can be faster/slower, use internal code/ext functions - 1 is manual string processing using for cycles (array.get) and ext functions - provided in case you want to implement your own logic, may sometimes be slower - 2 is a 2nd alternate implementation mostly done using built-in functions (array.indexof, array.slice, array.insert, array.remove, str.replace_all), attempts to minimize local scopes and dependency on ext functions, should generally be faster - 3 is a 3rd alternate (array.includes, array.fill) or a more advanced implementation (datetime3_str) with lots of params, giving you the most control over output - most functions have dependencies, such as const names, global arrays, inputs, other functions. P.S. Strings of Time may be closed unto themselves or have loose ends; they can vibrate, stretch, join or split. Function Groups: 1. Char Functions - repeat(str, num) - ascii_char(code) - ascii_code(char) - is_digit(char) - is_letter(char) - digit_to_int(char) - is_space_char(char) 2. Char Test and Lookup Functions - char_at(str, pos) - char_code_at(str, pos) - indexOf_char(str, char) - lastIndexOf_char(str, char) - nth_indexOf_char(str, char, num) - includes_char(str, char) 3. String Lookup Functions - indexOf(str, target) - lastIndexOf(str, target) - nth_indexOf(str, target, num) - indexesOf(str, target) - numIndexesOf(str, target) 4. String Conversion Functions - lowercase(str) - uppercase(str) 5. String Modification and Extraction Functions - split(str, separator) - insert(str, pos, new_str) - remove(str, pos, length) - insert_char(str, pos, char) - remove_char(str, pos) - reverse(str) - fill_char(str, char, start_pos, end_pos) - replace(str, target, new_str) - replace_first(str, target, new_str) - replace_last(str, target, new_str) - replace_nth(str, target, new_str, num) - replace_left(str, new_str) - replace_right(str, new_str) - replace_middle(str, pos, new_str) - left(str, num) - right(str, num) - first_char(str) - last_char(str) - truncate(str, max_len) - truncate_middle2(str, trunc_str, pos, max_len) - truncate_from2(str, trunc_str, pos, max_len, side) - concat(str1, str2, trunc_str, max_len, mode) - concat_from(str1, str2, trunc_str, max_len, side, mode) - trim(str) - substr(str, pos, length) - substring(str, start_pos, end_pos) - strip(str, mask, target, is_allowed) - extract_groups(str) - extract_numbers(str, d1, d2, mode) - str_to_float(str, d1, d2) - str_to_int(str) - extract_ranges(str, d1, d2, d3, type) 6. String Test Functions - includes(str, target) - starts_with(str, target) - ends_with(str, target) - str_compare(str1, str2) 7. Type Conversion Functions - tf_check2(tf) - tf_to_mins() - convert_tf(tf) - period_to_mins(tf) - convert_tf2(tf) - convert_tf3(tf) - bool_to_str(flag) - get_src(src_str) - get_size(size_str) - get_style(style) - get_bool(bool_str) - get_int(str) - get_float(str, d1, d2) - get_color(str, def_color) - color_tr2(col_str, transp) - get_month(str) - month_name(num, format) - weekday_name(num, format) - dayofweek_name(t) 8. Date and Time Functions - date_str(t, d) - time_str(t, d) - datetime_str(t, d1, d2) - date2_str(t, d, type) - time2_str(t, d, type) - datetime2_str(t, d1, d2, format1, format2) - date3_str(t, template) - time3_str(t, template) - datetime3_str(t, template) 9. Console Output & Helper Functions - echo1(con, str) - echo2(x, y, con, str) - echo3(v_shift, con, str, msg_color, text_size) - echo4(x, y, con, str, msg_style, msg_color, text_size, text_align, msg_xloc) - echo5(x, y, con, str, msg_style, msg_color, text_size, text_align, msg_xloc) - echo6(x, y, con, str) - echo7(v_shift, con, str, msg_color, text_size) - echo8(x, y, con, str, msg_style, msg_color, text_size, text_align, msg_xloc) - echo9(x, y, con, str, msg_style, msg_color, text_size, text_align, msg_xloc) - new_page(str, line_str, trunc_str, header_str, footer_str, length, page_count, page, mode)
Pine Script™ indicator
by RagingRocketBull
17
[blackcat] L2 Guppy Color BandLevel: 2 Background The Guppy Multiple Moving Average (GMMA) is a technical indicator that identifies changing trends, breakouts, and trading opportunities in the price of an asset by combining two sets of moving averages (MA) with different time periods. There is a short term group of MAs and a long term group of MAs. Function This script incoporates GMMA as a mid-term support/resistance levels which can indicates re-entry or entry signal. Short-term fast line and slow line are used to provide short term entries. Above GMMA, one can long and xlong, while under GMMA one can short or xshort. Key Signal a1~a7 ---> Guppy color band fastline --> short term fast line shortline --> slow term slow line safeline --> bull bear boundary Pros and Cons Pros: 1. easy observe price trend 2. it provides entry signal 3. it provides bull bear boundary Cons: Your feedbacks are welcome Remarks Courtesy of @LunaOwl " Rainbow Color Gradient" for GMMA color band in this script Readme In real life, I am a prolific inventor. I have successfully applied for more than 60 international and regional patents in the past 12 years. But in the past two years or so, I have tried to transfer my creativity to the development of trading strategies. Tradingview is the ideal platform for me. I am selecting and contributing some of the hundreds of scripts to publish in Tradingview community. Welcome everyone to interact with me to discuss these interesting pine scripts. The scripts posted are categorized into 5 levels according to my efforts or manhours put into these works. Level 1 : interesting script snippets or distinctive improvement from classic indicators or strategy. Level 1 scripts can usually appear in more complex indicators as a function module or element. Level 2 : composite indicator/strategy. By selecting or combining several independent or dependent functions or sub indicators in proper way, the composite script exhibits a resonance phenomenon which can filter out noise or fake trading signal to enhance trading confidence level. Level 3 : comprehensive indicator/strategy. They are simple trading systems based on my strategies. They are commonly containing several or all of entry signal, close signal, stop loss, take profit, re-entry, risk management, and position sizing techniques. Even some interesting fundamental and mass psychological aspects are incorporated. Level 4 : script snippets or functions that do not disclose source code. Interesting element that can reveal market laws and work as raw material for indicators and strategies. If you find Level 1~2 scripts are helpful, Level 4 is a private version that took me far more efforts to develop. Level 5 : indicator/strategy that do not disclose source code. private version of Level 3 script with my accumulated script processing skills or a large number of custom functions. I had a private function library built in past two years. Level 5 scripts use many of them to achieve private trading strategy.
Pine Script™ indicator
by blackcat1402
6
[blackcat] L2 Banker Fund Trajectory for IndiceLevel: 2 Background This script creates a model of banker fund (whale) with yellow and fuchsia candles. I use blue waves (b5) to detect oversold and overbought, which is more sensistive than candles. Function Use composite banker fund trajectory oversold and overbought for long and short entries, which works better for indice trading pairs Key Signal j --> banker fund fast line a2 --> banker funder slow line support --> dynamic support levels resistance --> dynamic resistance levels long --> oversold long entry short --> overbought short entry Pros and Cons This script is suitable for indice trading pairs. It will not work so well for other trading pairs due to overbought and oversold is not as stable as an index trading pair Remarks You feedbacks on index trading pairs are appreciated. Readme In real life, I am a prolific inventor. I have successfully applied for more than 60 international and regional patents in the past 12 years. But in the past two years or so, I have tried to transfer my creativity to the development of trading strategies. Tradingview is the ideal platform for me. I am selecting and contributing some of the hundreds of scripts to publish in Tradingview community. Welcome everyone to interact with me to discuss these interesting pine scripts. The scripts posted are categorized into 5 levels according to my efforts or manhours put into these works. Level 1 : interesting script snippets or distinctive improvement from classic indicators or strategy. Level 1 scripts can usually appear in more complex indicators as a function module or element. Level 2 : composite indicator/strategy. By selecting or combining several independent or dependent functions or sub indicators in proper way, the composite script exhibits a resonance phenomenon which can filter out noise or fake trading signal to enhance trading confidence level. Level 3 : comprehensive indicator/strategy. They are simple trading systems based on my strategies. They are commonly containing several or all of entry signal, close signal, stop loss, take profit, re-entry, risk management, and position sizing techniques. Even some interesting fundamental and mass psychological aspects are incorporated. Level 4 : script snippets or functions that do not disclose source code. Interesting element that can reveal market laws and work as raw material for indicators and strategies. If you find Level 1~2 scripts are helpful, Level 4 is a private version that took me far more efforts to develop. Level 5 : indicator/strategy that do not disclose source code. private version of Level 3 script with my accumulated script processing skills or a large number of custom functions. I had a private function library built in past two years. Level 5 scripts use many of them to achieve private trading strategy.
Pine Script™ indicator
by blackcat1402
29
[blackcat] L2 Ehlers RSI with NETLevel: 2 Background John F. Ehlers introuced RSI with Noise Elimination Technology (NET) in Dec, 2020. Function Many indicators produce more or less noisy output, resulting in false or delayed signals. Dr. Ehlers proposed “Noise Elimination Technology,” in Dec, 2020. He introduces using a Kendall correlation to reduce indicator noise and provide better clarification of the indicator direction. This approach attempts to reduce noise without using smoothing filters, which tend to introduce indicator lag and therefore, delayed decisions. With this script, I use his “MyRSI” indicator, which he introduced in his May 2018 article in S&C, by adding some Tradingview pine v4 code for the noise elimination technology. The indicator plots the MyRSI value as well as the value after applying NET to MyRSI. This de-noising technology uses the Kendall correlation of the indicator with a rising slope. Compared with a lowpass filter, this method does not delay the signals. The technology appears to work well in this example for removing the noise. But note that the NET function is not meant as a replacement of a lowpass or smoothing filter; its output is always in the -1 to +1 range, so it can be used for de-noising oscillators, but not, for instance, to generate a smoothed version of the price curve. Key Signal NET --> Ehlers RSI with NET fast line Trigger --> Ehlers RSI with NET slow line Pros and Cons 100% John F. Ehlers definition translation, even variable names are the same. This help readers who would like to use pine to read his book. Remarks The 99th script for Blackcat1402 John F. Ehlers Week publication. Readme In real life, I am a prolific inventor. I have successfully applied for more than 60 international and regional patents in the past 12 years. But in the past two years or so, I have tried to transfer my creativity to the development of trading strategies. Tradingview is the ideal platform for me. I am selecting and contributing some of the hundreds of scripts to publish in Tradingview community. Welcome everyone to interact with me to discuss these interesting pine scripts. The scripts posted are categorized into 5 levels according to my efforts or manhours put into these works. Level 1 : interesting script snippets or distinctive improvement from classic indicators or strategy. Level 1 scripts can usually appear in more complex indicators as a function module or element. Level 2 : composite indicator/strategy. By selecting or combining several independent or dependent functions or sub indicators in proper way, the composite script exhibits a resonance phenomenon which can filter out noise or fake trading signal to enhance trading confidence level. Level 3 : comprehensive indicator/strategy. They are simple trading systems based on my strategies. They are commonly containing several or all of entry signal, close signal, stop loss, take profit, re-entry, risk management, and position sizing techniques. Even some interesting fundamental and mass psychological aspects are incorporated. Level 4 : script snippets or functions that do not disclose source code. Interesting element that can reveal market laws and work as raw material for indicators and strategies. If you find Level 1~2 scripts are helpful, Level 4 is a private version that took me far more efforts to develop. Level 5 : indicator/strategy that do not disclose source code. private version of Level 3 script with my accumulated script processing skills or a large number of custom functions. I had a private function library built in past two years. Level 5 scripts use many of them to achieve private trading strategy.
Pine Script™ indicator
by blackcat1402